irclog2html for #oe on 20060220

00:02.34pb_mm, that is unfortunate
00:05.44njsso is "correct" even well-defined in this case? :-)
00:06.53reenooyes
00:07.19*** join/#oe _guillermo (n=guillerm@dslb-084-062-132-090.pools.arcor-ip.net)
00:07.47reenooa solution is correct if the set of it and the expected answer is first order consistent
00:08.42reenoochecking whether it is FO con is unfortunately only semi-decidable
00:09.20reenooand the prover used in the grading bot fails to find a proof (in finite time)
00:09.31*** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com)
00:10.46njsbut you could demonstrate such a proof, if only the bot would let you? :-)
00:11.17Harvyhi has anybody tried a build from scratch without the sources just that I have had some problems with fontconfig and now cairographics cvs access not downloading
00:12.45reenoonjs: if I had the expected solution, probably yes. (not manually though, but with a semi-automatic prover)
00:13.15njs*sigh* I want to take classes where this kind of problem arises :-)
00:14.02reenooheh. take classes on logic and you will run into this
00:14.28reenooor maybe advanced theoretical CS
00:14.52njsthe class on logic I took was all old-school pencil-and-paper-and-chalk
00:15.04njsand now I don't have time to take math classes anymore :-(
00:15.23Harvyfrom what I have seen on the site the bb files are wrong.. or maby me (ps any body see me)
00:15.39njsHarvy: see you, but I'm clueless, sorry.
00:16.21*** join/#oe rwhitby-away (n=rwhitby@nslu2-linux/rwhitby)
00:16.25reenooHarvy: cairo is moving to git, I believe. and anoncvs is being moved around on fd.o
00:17.01Harvycheers just a bit in the dark bout the problems trying to do a clean build
00:17.20*** join/#oe jott_ (n=j@e178104174.adsl.alicedsl.de)
00:17.25Harvyi have seen the change to git
00:18.04reenoonjs: heh, yeah, logic at a CS faculty ;) preferably one where people do research on theorem provers and stuff like they do here >:)
00:18.19*** join/#oe tmbin (i=XXX@dslb-082-083-084-115.pools.arcor-ip.net)
00:18.28Harvybut the cvs access is pserver:anoncvs@cvs.ca
00:20.38HarvyI can dragg ALL the files down by hand to my sources dir but would prefer a working setup
00:21.07Harvyany developers on at the moment?
00:22.03njsreenoo: yeah.  graydon keeps tantalizing me with interesting formal methods stuff, but so far I have resisted getting dragged in :-)
00:22.28*** join/#oe jott_ (n=j@e178104174.adsl.alicedsl.de)
00:27.23*** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby)
00:27.36*** join/#oe jott_ (n=j@e178104174.adsl.alicedsl.de)
00:33.03*** join/#oe idealm (n=ideal@58.33.57.17)
00:37.44*** join/#oe jott_ (n=j@e178104174.adsl.alicedsl.de)
00:41.51shadowsHarvy: i don't have commit access, or it would have been fixed
00:43.29Harvyif you could let somebody who does it would help
00:43.52Harvyjust trying to do a build from the start
00:44.11emtewhy change part of the files if the rest will break tomorrow?
00:44.16Harvycheers dude
00:44.34emteyou could just use the other repo ... if it still exists
00:44.51Harvywhat other repo
00:45.21emtetreke's
00:46.19Harvysurely a rc should build tho
00:47.08emteyou make false assumptions
00:47.32emtewe have no control over other projects sources or what they do with thier source trees
00:48.46Harvywell the inital download is from the oe server why is it not there anymore
00:49.01emteyou have the wrong ip
00:49.10emtedns currently does not work
00:49.52Harvydns for oe... is wrong
00:50.01shadowswhat happened with openzaurus.org expiring?
00:50.10shadowsis that project dead (in favor of Angstrom) ?
00:50.36emtewhat does the mailing lists say?
00:50.49Harvywhat is the ip then
00:53.43emtethrough*
01:00.36*** join/#oe noclouds (n=mhfan@60.166.50.113)
01:01.48*** join/#oe benlau (n=benlau@benlau.rd.ust.hk)
01:04.43emtehmm
01:04.45Harvygoing to have to sign off soon because I have work tommrow UK but will log cheers
01:04.56emteoesources.org works for me now
01:06.02emte192.216.230.225
01:07.06Harvyi will give it a try tommrow ...ttfn
01:07.13emtek
01:10.18emteand the play by play after
01:10.23*** join/#oe gremlin484 (n=gremlin4@ip68-13-173-187.om.om.cox.net)
01:23.27emtei think the 2.6 kernel has some serious bloat issues ...
01:23.43shadowsare you on amd64?
01:23.58shadowswhat do you mean bloat issues
01:24.02emtei am talking about jsut unpacking it
01:24.10emte/dev/hdc1             111G  105G     0 100% /backupfiles
01:24.19emtebuild$ rm -Rf tmp/work/h3600-linux/handhelds-sa-2.6-2.6.12-hh0+cvs20060219-r0
01:24.31emte/dev/hdc1             111G   93G   13G  89% /backupfiles
01:24.44emtetakes up 13Gb of room
01:24.54shadowswith the *.o yeah
01:25.06emteno, this is uncompiled
01:25.11shadowssource code itself is not so bad, considering it has support for a bazillion targets
01:25.16shadowserhM?
01:25.23emteit never made it past ./configure
01:26.23shadowsthe sources for kernel 2.6.15.4 on my desktop machine unpacked top out at 605M
01:26.49*** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg)
01:27.09emtei just pulled the source tar out of /sources and am unpacking by hand
01:27.22emtei'll do a du -h and see what i get
01:27.49shadowsremember if you have any sort of broken filesystem like reiserfs, 'du' will be incorrect
01:29.36Harvyreiseerfs is not broken
01:29.59emtelol
01:30.03emtei use XFS
01:30.15emte283M    kernel26
01:30.29Harvyxfs is painful
01:30.34emtelooks liek i generated 13Gb of garbage in taht compile loop
01:30.44emtei trust it far more than reiser
01:30.52shadowsXFS is excellent if you have no hardware or software or power problems
01:31.05shadowsand the moon is in the correct phase
01:31.15shadowswith god herself smiling on you
01:31.17emtei've never had an issue with XFS in 5 yrs
01:31.41emtecd kernel26
01:32.15Harvyyou have never had an un panned shutdown in 5 years
01:32.25emtesure i have
01:32.40emteliving on an island we have a couple powerouts every year
01:32.46Harvyand xfs was ok
01:32.49emteyup
01:33.26Harvyyou got lucky have yu tried fiery os
01:33.30emterieser was unrecoverable and ext3 ... lucky it suports ext2 mode
01:34.00emtefiery os, no
01:34.30chouimat|TVemte: I never had any problem with reiserfs ... and so far reiser4 was the best I tested
01:34.34Harvynever had aproblem with reisier
01:34.52Harvyfier rons on photocopiers
01:35.01emtei perfer my data being recoverable
01:35.13emteHarvy, oh wait
01:35.24emteyou mean Fiery ... the RIP server
01:35.30emteyeah i've used it
01:35.38emtehighend printing applications
01:36.05emtemore from a user perspective, never messed with it
01:36.24Harvyand if it dies so does the HW
01:36.32chouimat|TVemte: recoverable?? it was I have a huge tape backup system ;)
01:36.38chouimat|TVs/was/why
01:36.40emtelol
01:37.04Harvyrip is right
01:37.18*** join/#oe AvengerMoJo (n=alex@207.44.242.115)
01:37.31Harvyrest in peaces
01:37.49emterip as in raster image processing  ... lol
01:38.18emtefirey is great if your trying to print a 300MB+ image
01:38.45Harvyemte: ttfn thnks for the help
01:40.14emtenp
01:40.15emtebrb food
01:43.12*** join/#oe ai2097 (n=ai2097@pdpc/supporter/active/ai2097)
01:55.27ai2097Is there any way to get ipkg to update critical system packages without crashing the system in the process? I don't want to have to worry about my system getting b0rked every time I run ipkg upgrade and something like libc6 is in the list :/.
02:01.32*** join/#oe ScytheBlade1 (n=Death@about/pxe/ScytheBlade1)
02:03.48emteipag definatly needs some love on the client side
02:03.53emteipkg*
02:04.37ai2097Well, I guess another question would be, is ipkg actually intended for updating live/on-line systems?
02:05.11emteyes
02:06.05emtehttp://handhelds.org/moin/moin.cgi/Ipkg
02:07.55shadowsshould i be using the xlibs.bbclass directly?
02:08.16ai2097emte: Thanks.
02:09.05emteipkg is a great tool ... the frontend on the client needs some work
02:09.47emteshadows, what do you mean using?
02:09.56shadowslike, inheriting it?
02:10.23shadowscurrently theres a number of packages that define the CVS tree seperately, but they are all from freedesktop anon cvs
02:10.30shadowsso it should be fixed
02:10.34shadowsi'm going to submit a patch
02:10.39shadowsi wanted to know if that's okay
02:11.31emtei belive koen suggested changing it to ${FDO_CVS}
02:11.35emteor something like that
02:11.42shadowsokay
02:11.47emteit seems fdo changes every couple months
02:11.49shadowswhere  would FDO_CVS be defined?
02:11.51shadowsno
02:12.11shadowsit doesn't change every couple of months, this has been the case for 18 weeks and no one bothered to read the ML and update it
02:12.16shadowsnow i'm updating it
02:12.33emteits less 6months since fdo last changed their sources structure
02:13.12emteand i belive in local.conf with the others
02:14.50emteFeb 19 13:22:51 koen    should be move to $FDO_CVS or something
02:15.10shadowsoh
02:15.24shadowswell these particular ones are grabbing from the xlibs branch of fdo anoncvs
02:15.29shadowsso that actually looks okay
02:15.42shadowsi'm changing it to an xlibs thing, easy enough to change later
02:15.48emtexcb apperently is the only change
02:16.03emteatleast as far as fdo's list has stated
02:16.56emteFeb 19 14:03:26 pb_     zecke: thinking of the xlib thing that shadows mentioned earlier, you might find http://lists.freedesktop.org/archives/xorg/2006-February/013113.html interesting.
02:42.15*** join/#oe Zero_Cha1s (n=zero@pool-71-240-2-169.pitt.east.verizon.net)
02:52.53emtehmm
02:53.01shadowsi'm going through all the files now and updating
02:53.07emtehas BBDEBUG stopped working ?
02:53.09shadowsit's an unbelievable quantity of files
02:53.33emtei think thats why $FDO_CVS was suggested
02:53.57shadowsi split it up into three bbclass'es
02:54.04shadowsit works more easily that way i think
02:54.05emtewe had to do the same thing before for all the fdo projects a few months back
03:00.20emtehrm
03:00.49shadowsonly 3 more bb's to go
03:00.52shadowsthen i will make a diff
03:07.36emtehmm
03:07.38emtesilly silly
03:08.06shadowshttp://bugs.treke.net/show_bug.cgi?id=706
03:12.55emtehmm
03:13.01emteJustinP, you awake?
03:13.10emteor pb_
03:13.59emtecan one of you please push http://bugs.treke.net/show_bug.cgi?id=445
03:14.15emteit shoudl have been done months ago
03:24.18JustinPemte: yeah, just wasn't online
03:24.23JustinPemte: what's up?
03:24.39emteactually ignore that request
03:24.47emtethat change wont work
03:25.42emtestrange ... why is it failing ...
03:26.45JustinPk
03:27.34emteNOTE: Handling BitBake files: / (1596/3074) [51 %]ERROR: /backupfiles/biohazard/openembedded/org.openembedded.dev/packages/linux/handhelds-sa-2.6_cvs.bb:27: unparsed line: 'do_configure()' while parsing /backupfiles/biohazard/openembedded/org.openembedded.dev/packages/linux/handhelds-sa-2.6_cvs.bb
03:27.59emtewhy is it not parsing ...
03:28.08JustinPshadows: good...except that you don't need to change PR if you change the SRC_URI that way...
03:30.01*** join/#oe noclouds (n=mhfan@60.166.50.113)
03:32.29*** join/#oe aquadran_ (i=pablo@scummvm/undead/aquadran)
03:36.48emteokay it worked this time
03:36.57emtei must of had a bad char
03:37.11emteJustinP, you wanna push this  http://bugs.treke.net/show_bug.cgi?id=445
04:01.41*** join/#oe REdOG (n=REdOG@68-117-202-171.dhcp.opls.la.charter.com)
04:15.44emtewell i got h3600 sa-2.6 atleast configureing and partially building  :)
04:15.47emtehttp://oe.pastebin.com/563879
04:16.14emteheed to figure out what happened to   arch/arm/mach-sa1100/h3600.c:47:36: asm/hardware/gpio_keys.h: No such file or directory
04:16.21emteneed*
04:23.33*** join/#oe dkey| (n=dkey@L0001P18.dipool.highway.telekom.at)
04:24.19*** join/#oe ScytheBlade1 (n=Death@about/pxe/ScytheBlade1)
04:30.37emtehrm...
04:37.12*** join/#oe Geo_KM (n=keith@ppp47-111.lns2.syd6.internode.on.net)
04:44.54JustinPemte: I do?
04:47.25emtelooks like i'll be adding somemore stuff to it soon
04:50.29JustinPwell, if it's not working.....
04:58.56emtethere
04:59.07emtecleaned out soem files now i should be able to find it
04:59.17*** join/#oe CSMan (n=csman@67.71.26.84)
05:04.42shadowsJustinP: i was told that all builds need PR
05:05.09emteits debatable on your changes i think
05:05.31shadowswell someone needed to do it
05:05.34shadowsi did it.
05:05.46emteno, not the changes themselves
05:05.58emteif PR neede to be changed
05:06.02emteneeded*
05:06.31shadowsemte: that should be "do_configure ()"  i think
05:06.33shadowsnotice the space
05:06.39shadowsmake sure it has the space AFAIK
05:06.52emtenah it wasnt that
05:07.06emteit was an invis char i inserted
05:07.10shadowsohhh okay
05:07.54emteteaches me to copy and paste out of my browser
05:07.58emte:P
05:08.14emtevia gpm
05:08.47emtehurry up slocate ....
05:08.56emtei need smaller hdds
05:09.08emtethen it wouldnt take so long
05:10.50emteAHA!!!!
05:10.57emte<PROTECTED>
05:11.15emtesilly path change
05:11.30emtehrm ...
05:11.49emteon second thought ... how many files do i have to patch now .... 6?
05:14.51*** join/#oe minipanda (n=hzhang@218.17.92.74)
05:20.25JustinPshadows: 1) I was wrong, 2) no
05:20.58JustinPshadows: I told you that all builds need PR and they don't *need* them if they haven't been updated (i.e. default is r0)
05:21.35JustinPshadows: and also, SRC_URI changes like the ones in your patch don't need a PR bump. There's no build change and no actual difference in the ipks built so there's no need to make people rebuild
05:22.00JustinPshadows: of course, to fix those SRC_URIs we could just use a simple sed script...
05:22.11emteon the otherside a PR bump is a marker for the URI change
05:22.13poliIs it some usual thing for gdb to "miss" addresses?
05:22.27poliI am getting an error from an address on the heap :S
05:23.37JustinPemte: marker?
05:24.04emteindicator when the URI change happened
05:24.18emtefrom a historical aspect
05:25.57emtelike i said it could be debated either way
05:26.06JustinPnot needed
05:26.10JustinPthe revision # is enough
05:26.33JustinPif the code or build doesn't change there's no reason to bump PR
05:26.37emtePR is the revision number
05:26.56JustinPPR is used to tell the build system to build a new version and the installer to install a new version
05:27.04JustinPthere is no reason to rebuild or upgrade with this change
05:27.16JustinPif you already have it built, using a new source will make no diff
05:27.59JustinPRP: looks like the interrupt isn't being called at all
05:28.08emtecorrect, but i belive if you already that the source version it will ignore the URI anyway
05:28.18emtes/that/have
05:28.35JustinPRP: and nothing is happening when I insert/remove the remote (although inserting and removing the module shows some output now)
05:29.01JustinPemte: ?
05:29.20JustinPemte: a new URI will cause a new fetch, yes
05:29.38shadowsokay, noted
05:29.43emtereally? never noticed it here ...
05:29.44shadowsi'm going off what people told me to do before
05:29.47JustinPemte: it won't use the old tarball as the tarball name has the URI in it
05:29.51emtecept with cvs which is normal
05:29.56shadowsand also my experience w/ Gentoo
05:29.59JustinPshadows: I must not have explained it very well before
05:30.09shadowshm
05:30.14*** join/#oe decca (n=decca@203-59-28-79.perm.iinet.net.au)
05:30.19shadowsfeel free to patch it yourself ;)
05:30.41JustinPemte: do you know anything about kernel interrupts?
05:30.46shadowsi feel it necessary to bump all the revisions and see what breaks
05:30.55emteJustinP, not enough to help you
05:31.12JustinPshadows: clean/rebuild
05:31.15*** join/#oe Zero_Chaos (n=zero@pool-70-17-168-210.pitt.east.verizon.net)
05:31.15shadows'cause right now, gpe/opie targets are going to be possible to build
05:31.38shadowss/are/are not/
05:32.41shadowsJustinP: the whole thing is going to need an overhaul soon enough
05:33.06shadowsthis is temporary "emergancy fix" until it gets changed
05:36.07JustinP...
05:36.11JustinPwhat's the "real" fix?
05:36.33JustinPBTW, if anyone is willing to check this out, the interrupt isn't being called: http://oe.reversefold.com/sharpsl-rc.patch
05:40.11*** join/#oe AvengerMoJo (n=alex@207.44.242.115)
05:41.45shadowsJustinP: the "real" fix is to mirror snapshots on an OE mirrorsite
05:41.48shadowsand reference that
05:45.55emteshadows, thats not a real fix
05:46.10emteit has its own inherit issues
05:46.31emtemainly maintainance and staleness
05:47.47JustinPthe real fix is to have *releases* which work
05:48.11emtelol
05:49.09JustinPeither that or use the releases and then add patches which get it up to the point in CVS that we need
05:56.53shadowsright
05:57.05shadowsthat's what i mean, we shouldn't be depending on some random foo cvs server
05:57.40*** join/#oe Anst (n=anst@198.36.32.13)
05:58.10*** part/#oe Anst (n=anst@198.36.32.13)
05:59.20emtelolalright
05:59.26emtealright*
05:59.34emtelest see what my current mangling has done
06:00.45emtewanna see my patch so far?
06:00.48emtehttp://oe.pastebin.com/563937
06:01.02emte516 lines of fun
06:01.44emtehmm
06:01.48emteit didnt liek it
06:03.13emtehmm
06:03.15emtei wonder
06:04.37JustinPemte: jeez.....
06:05.00emtewho me?
06:05.02emte:P
06:05.18emtethe first 490 lines are changes in the defconfig
06:06.11emtebasically the difference between the defconfig and runing it and saving it again via make menuconfig
06:06.40JustinP:-|
06:07.02emtei think the kernel-crew's defauly is a bit stale
06:07.06emtedefault*
06:07.20emtehence me fixing header paths
06:10.40*** join/#oe [lala] (n=lala@p54B387DA.dip0.t-ipconnect.de)
06:10.42emtewhoops spelling mistake :(
06:10.52*** join/#oe _law_ (n=law@mail.stiftadmont.at)
06:11.48*** part/#oe AvengerMoJo (n=alex@207.44.242.115)
06:22.22*** join/#oe guillermo_ (n=guillerm@dslb-084-062-135-124.pools.arcor-ip.net)
06:22.49emtehmm
06:25.22emtegrr
06:26.12emtehttp://www.handhelds.org/hypermail/kernel-discuss/13/1335.html
07:01.34JustinPgrrrr
07:01.38JustinPinterrupt!
07:05.00*** part/#oe ade|desk (n=adavey@194.200.143.249)
07:11.43*** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby)
07:15.46emteokay finally ...
07:16.03emtei got 2.6.15 patched and compiling
07:18.32*** join/#oe gremlin[it]work (n=gremlin@host198-151.pool212171.interbusiness.it)
07:19.38*** join/#oe dyoung-away (n=dyoung@nslu2-linux/dyoung)
07:29.33emtehey gremlin[it]work i found the threads on your kernel stuff :)
07:31.55gremlin[it]workyes :)
07:32.13emtei wish i had found em earlier
07:32.39gremlin[it]worki'll send a patch this evening for micro_key ...
07:32.41gremlin[it]workwhy ?
07:33.02emtespent a while patching paths before i found yours
07:33.56gremlin[it]workfor h3600 ?
07:34.00emteyup
07:35.41gremlin[it]workit's about 6/9 months i start to take care oh h3600 for kernel 2.6 ;)
07:36.25emteyeah, its just not in the dev repo ... not sure which branch your on
07:37.32gremlin[it]workno i'm working just on kernel not on oe ...
07:38.03emteyeah, thats what i am thinking
07:38.28*** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl)
07:39.02gremlin[it]worki have done some change on oe, i have a different h3600 machine to build with k26 ...
07:46.53gremlin[it]workprobably i'll put my difference on my site ...
07:56.55*** join/#oe alan|home (n=alan@ARouen-152-1-23-146.w83-115.abo.wanadoo.fr)
07:57.31alan|homemorning
08:01.50*** join/#oe Ifaistos (n=stelios@dslcustomer169.vivodi.gr)
08:02.08IfaistosGood morning  all !
08:19.15hrw|workmmornign
08:21.56*** join/#oe decca (n=decca@203-59-28-79.perm.iinet.net.au)
08:22.56*** join/#oe lazy_marmot (n=lazy_mar@host-62-245-231-14.customer.m-online.net)
08:27.20*** join/#oe rob_w|mis (n=rob_w@p549BC4A4.dip0.t-ipconnect.de)
08:28.10*** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl)
08:53.42koengood mornning all
08:59.50*** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl)
09:02.25*** join/#oe koobla (n=Simon@wall4.soft.uni-linz.ac.at)
09:06.17JustinPwoohoo!
09:06.23JustinPI'm getting interrupts
09:08.00hrw|workre
09:09.43JustinPand output
09:09.49JustinPno events, though
09:09.57JustinPat least I'm getting closer
09:13.55CoreDump|homemorning
09:16.22koenhey CoreDump|home
09:19.30CoreDump|homeyay ipkg upgrade fubar'ed my ROM yet again
09:20.01koenthat makes no sense
09:20.11koenif it's Read Only, how can ipkg mess with it?
09:20.53CoreDump|home~lart koen for pointing out the obvious
09:21.04koen:)
09:21.11*** join/#oe [lala] (n=lala@ip-217-18-177-19.reverse.dsi.net)
09:21.29gremlin[it]workmhhh with a cold shower koen can completelly wakeup :) :) :)
09:21.50gremlin[it]workkoe off-topic : what's your ppc board ?
09:22.31koengremlin[it]work: the only powerpc board I have is my powerbook
09:22.41koenthe rest is either arm, armeb or mips
09:22.45gremlin[it]workthe loft board ?
09:22.51koenthat's armeb
09:23.11RPmorning all
09:23.16koengremlin[it]work: http://www.giantshoulderinc.com/hardware.html
09:23.18koenhey RP
09:23.38hrw|workhi RP CoreDump|home
09:24.23hrw|workhi XorA
09:24.31XorAmorning
09:24.45koenhttp://ewi546.ewi.utwente.nl/tinderbox/showbuilds.pl?tree=OpenEmbeddedBuilds
09:24.52koenwe have a working tinderbox again
09:24.59hrw|work"every project has a phase when all engineers should be kill and product shipped" is my feeling about OZ 3.5.4
09:25.01koenthanks to Zecke
09:25.17koenhey hrw|work & XorA
09:25.46CoreDump|homedid anyone try abiword recently? It compiles and installs fine but crashes on start-up with an X error
09:26.03CoreDump|homehrw|work: =)
09:26.27koenCoreDump|home: http://handhelds.org/~bugzilla/show_bug.cgi?id=1520
09:26.51hrw|workCoreDump|home: we had plans to ship it before fosdem
09:27.03hrw|workCoreDump|home: currently I feel that we will ship it in may or later...
09:27.04CoreDump|homekoen: great thanks!
09:27.17CoreDump|homehrw|work: what's holding it up?
09:27.51hrw|workCoreDump|home: fscking keylauncher/matchbox problem in gpe
09:28.10hrw|workCoreDump|home: I vote for removing keylaunch at all from c*0 devices
09:28.13CoreDump|homethen remove keylauncher and configure the keys via matchbox's config file
09:28.17CoreDump|homeyep
09:28.17koenhrw|work: don't ship keylaunch
09:28.50CoreDump|homeinterestingly enough, GPE from .dev works fine heh
09:29.15CoreDump|homeor maybe the newer xserver-common wasn't pushed into .dev only .oz
09:30.03CoreDump|homeAlso, personally, I would disable locale-base-* postinst completely
09:30.49hrw|work~seen mickeyl
09:30.51ibotmickeyl is currently on #oe #opie #handhelds.org. Has said a total of 11 messages. Is idling for 19h 57m 3s, last said: 'argouml?'.
09:32.58JustinPRP: oh, hey, morning
09:33.09JustinPRP: I'm getting interrupts :-)
09:33.23JustinPRP: it looks like it's all good, except for the ranges for the buttons.....
09:33.55JustinPRP: the values output by get_remocon_raw() are not unique for the different buttons...
09:34.29RPJustinP: That doesn't sound good :-/
09:34.31JustinPRP: some of the buttons give different values, but most don't
09:34.54RPJustinP: Could your debugging code  be interfering with the measurements somehow?
09:35.01JustinPRP: ATM, only vol up and vol down will work...:-|
09:35.09RPI guess we need to figure out exactly what its measuring...
09:35.28JustinPI doubt anything I added could have interfered....but I may be wrong
09:35.42JustinPMAX1111_REMCOM could be wrong, though
09:35.53JustinPyou had it commented as possibly 0u, so I made it that
09:36.25JustinPnot sure what it refers to exactly, but it's used in the call to sharpsl_pm_pxa_read_max1111 to get the values I'm talking about
09:36.36JustinPhttp://oe.reversefold.com/sharpsl-rc.patch
09:36.54RPJustinP: Its the ADC channel on the MAX1111 I think the headphones are connected to
09:37.04RPSee the Maxim MAX1111 datasheet
09:37.24JustinPah.....well, I am getting different values for some of the buttons....
09:37.58koenthat's a start
09:39.10JustinPI'm just recompiling with altered constants to that I can hopefully see something come across the input device ^_^
09:39.35RPI'd compare how its calling the max1111 functions with that in the sharp driver.
09:39.59RPI'm wondering if corgi_ssp might be broken somehow...
09:40.35CIA-403koen 07org.oe.dev * r244cbc11... 10/conf/distro/angstrom-2006.9.conf: angstrom-2006.9: set distro version to test
09:42.17JustinPhmmmm
09:42.26JustinP1u
09:42.39JustinPwith a bunch of bit-shifting....
09:42.59JustinP(1u << MAXCTRL_PD0_SH) | (1u << MAXCTRL_PD1_SH) | (1u << MAXCTRL_SGL_SH) | (1u << MAXCTRL_UNI_SH) | (0  << MAXCTRL_SEL_SH) | (1u <<MAXCTRL_STR_SH)
09:43.46JustinP(I have no idea what u means)
09:44.27*** join/#oe decc0r (n=decca@203-59-28-79.perm.iinet.net.au)
09:44.36RPIt means unsigned so its just a 1 character
09:44.58JustinPah....wonder why I hadn't learned that previously...
09:45.30JustinPis the shitfing to have it work runtime with different devices or something....?
09:46.50RPIts just so you can see the bitbstatus of all the regsisters like PD0, PD!, SGL, etc
09:47.46JustinPcould that be the problem then? since we're sending in 0u (or 1u now)
09:48.57*** join/#oe do13_ (i=do13@antilope.in-berlin.de)
09:49.03do13_morning all
09:49.09JustinPdo13_: morning
09:49.11RPJustinP: The commands should be identical
09:49.14RPhi dirk
09:49.44do13_Hi Richard, JustinP
09:49.56JustinPRP: so 1u == all that bit-shifting?
09:50.22RPJustinP: no, See +return corgi_ssp_max1111_get((channel << MAXCTRL_SEL_SH) | MAXCTRL_PD0 | MAXCTRL_PD1
09:50.22RP+| MAXCTRL_SGL | MAXCTRL_UNI | MAXCTRL_STR);
09:50.48JustinPhmmm, ok
09:51.01JustinPoh
09:51.02JustinPpff
09:51.08*** join/#oe cyphunk (n=cyphunk@tor/session/x-072ff0c8b4c62072)
09:51.11RPI suspect MAXCTRL_PD0 = (1u << MAXCTRL_PD0_SH)
09:51.13JustinPthey were defined in the patch
09:51.24hrw|workhi Dirk
09:51.35RPIts also defined in the sharpsl_pm code
09:51.50do13_hey Marcin
09:51.51cyphunkcan the http://ipkgfind.nslu2-linux.org/ package search be trusted?  Finding it hard to believe that libupnp is not in there yet
09:52.10JustinPoh....
09:52.13JustinP~lart me
09:52.25koencyphunk: it can be trusted
09:52.37CIA-403koen 07org.oe.dev * r0f3ce981... 10/conf/distro/angstrom.conf:
09:52.37CIA-4angstrom.conf:
09:52.37CIA-4* set default maintainer
09:52.37CIA-4* put angstrom and version into image names
09:52.38hrw|workOE & OZ sucks badly when it comes to PR and informations...
09:52.39koencyphunk: if it builds, ask NA|Zzz to include it when he wakes up
09:53.14cyphunkkoen: it does build.... will do
09:54.33koenRP: is the git patch for lib/bb in svn yet?
09:54.44koenit seems we might need it for xlibs :(
09:55.02JustinPhmmm, no...
09:55.42hrw|workkoen: iirc git fetcher is in trunk
09:56.14JustinPlooks like 0u would give me the same thing as the Sharp code
09:56.31koenhrw|work: yes, but it's broken
09:56.45koenhrw|work: it needs http://www.rpsys.net/openzaurus/temp/bitbake_git-r0.patch
10:00.00hrw|workhttp://bugs.openembedded.org/show_bug.cgi?id=610 is useless probably (its gpe)
10:00.05JustinPok, it's 2AM, I'm too tired to keep hacking
10:00.39JustinPRP: I would appreciate it if you could take a quick look and see if perhaps the corgi_ssp stuff is broken...
10:00.39RPkoen: not yet. Its not going to happen until this evening. Too many other things to worry about today :-/
10:01.08JustinPRP: it could also be the MAXCTRL constants defined in the patch perhaps...
10:01.13koenRP: no hurry, I have it applied locally :)
10:01.16RPJustinP: I suspect the bit bang code from the original sharp driver might ben needed
10:01.24JustinPlovely
10:01.27*** part/#oe NA|Zzz (n=foo@220-253-9-123.VIC.netspace.net.au)
10:01.45RPIt the bit bang code was for the max1111, that would be a problem
10:02.36JustinPwell, it seems like I'm getting about 3 bits in my value...largest I've seen is 5
10:03.15JustinPof course I'm completely speculating
10:03.50JustinPanyway, I'm off to bed. Perhaps tomorrow I can look into the ssp code, although I of course no nothing about that either....
10:04.10JustinPat least it's coming along
10:04.15JustinPnight
10:04.36RPJustinP: I'll try and have a look at the ssp code to refresh my memory. 'night
10:05.07koen'night JustinP
10:08.39XorA~seen mickeyl
10:08.43ibotmickeyl is currently on #oe #opie #handhelds.org. Has said a total of 11 messages. Is idling for 20h 34m 55s, last said: 'argouml?'.
10:14.15ldcsomeone wanna submit a patch for perl_5.8.7.bb
10:14.31XorAldc: what sort of patch?
10:14.35ldcFor gentoo the following fixes are needed
10:14.38ldc<PROTECTED>
10:14.38ldc<PROTECTED>
10:14.38ldc<PROTECTED>
10:17.24ldcjust cant understand why they use hardcoded path's in errno_pm.pl
10:18.42XorAldc: You should attach to a bug in bugs.treke.net
10:19.51*** join/#oe decca (n=decca@203-59-28-79.perm.iinet.net.au)
10:20.54ldcxora: well, not really using a clean OE tree, but this problem exists in the clean OE tree too
10:23.53*** join/#oe subduerr (n=chopstix@cpe-66-8-255-241.hawaii.res.rr.com)
10:25.16XorAldc: well bug report it anyway, its a bug that needs fixed and perl has a maintainer
10:29.01*** join/#oe hrw|work (n=hrw@host-ip170-158.crowley.pl)
10:29.29*** join/#oe zinga (n=arnaudb@186.80-203-227.nextgentel.com)
10:29.49*** join/#oe idealm (n=ideal@58.33.57.17)
10:34.45*** join/#oe obergix[work] (n=olivier@mag77-1-82-238-13-91.fbx.proxad.net)
10:39.51*** join/#oe subduerr (n=chopstix@cpe-66-8-255-241.hawaii.res.rr.com)
10:40.16CoreDump|homeNOTE: multiple providers are available (glibc, glibc-intermediate);
10:40.17CoreDump|homeNOTE: consider defining PREFERRED_PROVIDER_virtual/arm-linux-libc-for-gcc
10:40.44CoreDump|homeAm I right to assume that if  PREFERRED_PROVIDER is not set, OE uses the first one in the list?
10:41.08koenno idea, but in your case both options are fine
10:41.21CoreDump|homethanks =)
10:41.23*** part/#oe subduerr (n=chopstix@cpe-66-8-255-241.hawaii.res.rr.com)
10:41.25koenalthough the glibc-i way is a bit longer
10:42.48koenwith eabi we'd need glibc-i
10:43.17CoreDump|homeOne would thing something like that would be set in openzaurus*conf
10:44.24CoreDump|home~lart minimo mirror
10:44.35CIA-403koen 07org.oe.dev * reb1daf07... 10/packages/linux/ (4 files in 4 dirs): handhelds-pxa: update to 2.6.15, include patches and new defconfigs
10:45.37*** join/#oe subdue (n=chopstix@64.129.5.131)
10:55.15CIA-403xora 07org.oe.dev * r1b17d5ea... 10/packages/offlineimap/offlineimap_4.0.11.bb:
10:55.15CIA-4offlineimap_4.0.11.bb : add a new version with some proper dependecies
10:55.15CIA-4on the right python modules.
10:56.10*** join/#oe cyphunk_ (n=cyphunk@tor/session/x-1dd88d762bd462c6)
11:00.46*** join/#oe dkey (n=dkey@L0001P18.dipool.highway.telekom.at)
11:07.07*** join/#oe france (n=france@pool-151-203-238-32.bos.east.verizon.net)
11:11.18RPkoen: You had an error recently about a versioned dependency problem in gpe-session-scripts. Can you still reporduce it?
11:11.29koensure
11:11.38koenbitbake gpe-sessionscripts with a recent bitbake
11:11.54koengpe-session-scripts that is
11:12.51RPkoen: ok, it was from a .bb in .dev?
11:14.30hrw|work~curse tosa and poodle for being so unpopular
11:14.31ibotMay you be reincarnated as a Windows XP administrator, tosa and poodle for being so unpopular !
11:14.59RPkoen: It reproduces - I'll look into it...
11:26.29*** join/#oe lrg|home (n=liam@exize.demon.co.uk)
11:33.34*** join/#oe obergix[work] (n=olivier@mag77-1-82-238-13-91.fbx.proxad.net)
11:56.28rob_w|miskergoth,  could you inform me about tslib input raw a bit .. how do i get a touchscreen supported by it ?
12:07.36*** join/#oe LordVan (n=lordvan@i-195-137-105-19.freedom2surf.net)
12:12.17*** join/#oe rwhitby-away (n=rwhitby@nslu2-linux/rwhitby)
12:19.25*** join/#oe mrz80 (i=1000@caledonia.cns.ufl.edu)
12:22.47*** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg)
12:30.43hrw|worksomeone want to test up-to-date hostap stuff?
12:43.17*** join/#oe frank__ (n=user@84.92.70.37)
12:44.09*** join/#oe cyphunk_ (n=cyphunk@tor/session/x-ecb7ade033216d84)
12:44.59*** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl)
12:46.59katossi_unianyone successful with e-image or e-image-core?
12:47.34*** join/#oe gremlin[it]work (n=gremlin@host145-151.pool212171.interbusiness.it)
12:49.21CIA-403pH5 07org.oe.dev * r7130132b... 10/packages/linux/handhelds-pxa-2.6/ipaq-pxa270/defconfig:
12:49.21CIA-4handhelds-pxa-2.6: upgrade hx4700 defconfig to 2.6.15-hh0
12:49.21CIA-4- reverts an accidental downgrade
12:50.41CIA-403koen 07org.oe.dev * r3abff1bf... 10/packages/linux/ep93xx-kernel_2.6.15.bb:
12:50.41CIA-4ep93xx kernel: update to derevo2
12:50.41CIA-4* serial should be working
12:50.41CIA-4* ethernet might be working
12:52.51*** join/#oe Jenna (n=cherryRe@209.8.233.207)
12:53.15*** part/#oe cyphunk_ (n=cyphunk@tor/session/x-ecb7ade033216d84)
12:53.17*** part/#oe Jenna (n=cherryRe@209.8.233.207)
12:53.18*** join/#oe cyphunk_ (n=cyphunk@tor/session/x-ecb7ade033216d84)
12:53.19hrw|worksomeone know which email Schurig use in OE bugtracker?
12:53.54koen|awayAngstrom-gpe-image-test-20060220-ep93xx.rootfs.tar.bz2
12:53.55koen|awayyay
12:53.59koen|awaygcc 4 works
12:54.16CIA-403pH5 07org.oe.dev * r5940fb0f... 10/packages/avahi/avahi_0.6.7.bb:
12:54.16CIA-4avahi: add 0.6.7
12:54.16CIA-4- See http://avahi.org/milestone/Avahi%200.6.7 and
12:54.17CIA-4<PROTECTED>
12:54.43gremlin[it]workmhh just to know what board with ep93xx ???
12:55.37koen|awaygremlin[it]work: http://dominion.kabel.utwente.nl/koen/ep93xx/ http://glomationinc.com/products_9312-sx.html
12:56.44gremlin[it]worki know glomation one specially 9315 seem really cute;)
13:02.46*** join/#oe darkschneider (n=gab@213-140-6-96.ip.fastwebnet.it)
13:03.20*** join/#oe hrw|work (n=hrw@host-ip170-158.crowley.pl)
13:03.25hrw|workbugs: 707, 708, 709 need someone familiar with hostap, wpa etc things
13:05.50*** join/#oe zecke (n=ich@145.253.107.2)
13:10.40CIA-403pH5 07org.oe.dev * rf25635ce... 10/packages/avahi/ (avahi_0.6.3.bb avahi_0.6.5.bb avahi_0.6.7.bb): avahi: drop 0.6.3, fixes suggested by BitTest
13:10.45CIA-403pH5 07org.oe.dev * r1077a62e... 10/packages/libdaemon/ (libdaemon_0.3.bb libdaemon_0.10.bb libdaemon_0.6.bb): libdaemon: drop 0.3, fixes suggested by BitTest
13:12.50chouimatmorning
13:13.48*** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby)
13:21.04*** join/#oe Cwiiis (n=cwiiis@host86-136-192-243.range86-136.btcentralplus.com)
13:40.11*** join/#oe rwhitby-away (n=rwhitby@nslu2-linux/rwhitby)
13:42.58*** join/#oe cyphunk (n=cyphunk@tor/session/x-8d9ed041bcfc581a)
13:50.28*** join/#oe rwhitby-nslu2 (n=rwhitby@nslu2-linux/rwhitby)
13:57.01*** join/#oe hrw|work (n=hrw@host-ip170-158.crowley.pl)
13:57.43*** join/#oe greentux (n=m@ip-217-18-177-19.reverse.dsi.net)
13:57.50greentuxhello
13:57.57XorAhey greentux
13:58.32hrw|workhi greentux
14:01.38hrw|workhi drw
14:01.53greentuxhi hrw|work
14:02.02greentuxhi XorA
14:02.32zeckehey
14:03.25drwmorning
14:04.32katossi_unimy gps is not working right in my akita when I do a 'cat /dev/ttyUSB0', I get blocks of lines, but it does work with minicom, could it be any buffering problem with cat?
14:07.38*** join/#oe luke-jr_ (n=luke-jr@user-0c93tin.cable.mindspring.com)
14:23.52*** join/#oe decca (n=decca@203-59-28-79.perm.iinet.net.au)
14:28.31gremlin[it]workkoen|away, can u give me (us) some kind of review of the glomation board ?
14:29.15*** join/#oe alan|home (n=alan@ARouen-152-1-39-159.w83-115.abo.wanadoo.fr)
14:37.36koengremlin[it]work: I'll have to boot 2.6 first
14:38.03gremlin[it]workouch !!!
14:39.36koenIt's using some 'standard' which differs from what I want
14:40.23gremlin[it]workkorean standard :)
14:41.32gremlin[it]workmainly i like to know about speed, gcc support for maverick, and if u was able to find the bsdl (jtag) file for cirrus cpu
14:43.10koengremlin[it]work: we (actually [g2]) are going to work on gcc support for maverick
14:43.26koengremlin[it]work: but you can use crunch already if you use the toolchain from cirrus
14:47.00*** join/#oe _law_ (n=law@mail.stiftadmont.at)
14:47.57*** join/#oe REdOG (n=REdOG@mail.tonychachere.com)
14:50.36*** join/#oe Bernardo (n=Bernardo@sourcemage/Bernardo)
14:50.41Bernardohello guys
14:52.01hrw|workhi Jose
14:52.10*** join/#oe AvengerMoJo (n=alex@207.44.242.115)
15:02.40Bernardohrw|work: saw your message on the list, about oz354
15:03.04BernardoI'm sorry to say I haven't had much time to test stuff on my akita
15:03.45Bernardobut what I did seems to work without major bugs
15:04.31Bernardoonly problem I found with a 354 image I built a week ago was with libxine playing qt movies, but that is minor
15:07.20hrw|workBernardo: no problem - over 100 users got url to images
15:07.51*** join/#oe benlau (n=benlau@221.125.13.158)
15:11.55*** join/#oe tmbinc (i=XXX@dslb-082-083-089-088.pools.arcor-ip.net)
15:31.57hrw|workCoreDump|afk: any plans to update altboot in .oz354fam083? I would like to get 'rootfs from tarballs' functionality in oz 3.5.4
15:36.49*** join/#oe eumel (n=chatzill@p548316E4.dip0.t-ipconnect.de)
15:38.38cyphunkvery basic q: so to setup a package to build with my local oe I need to 1)create a .bb and 2) create an ipkg for the package?  is that all (in general)?
15:38.57XorAcyphunk: 2) will be done for you if your bb is right
15:39.06cyphunkXorA: thanks
15:45.50cyphunkunder what conditions are custom do_* routines needed?
15:46.23cyphunkor will I need a do_install defined for all the files I want installed regardless of condition of the packages original makefile?
15:46.40XorAcyphunk: if make install works then you shouldnt need a custom do_install
15:46.50cyphunkrighto
15:46.51cyphunkthanks
15:47.59XorAsometime makefiles use custom variables for install dirs and you need to call oe_runmake in a custom do_install with these variable set correctly, that sort of thing
15:48.08XorAautotools stuff is normally very simple
15:48.30cyphunkokay, noted
15:56.15*** join/#oe obergix[work] (n=olivier@mag77-1-82-238-13-91.fbx.proxad.net)
16:01.00*** join/#oe alan|home (n=alan@ARouen-152-1-103-128.w86-205.abo.wanadoo.fr)
16:02.39*** join/#oe law_ (n=_law_@213.173.86.202)
16:18.24*** join/#oe CosmicPenguin (n=nobody@aus-ext-proxy02.amd.com)
16:21.25[g2]gremlin[it]work are you looking for JTAG on the cirrus for debugging ?
16:21.31[g2]or for flashing the bootloader ?
16:22.03[g2]The Cirrus EP93xx family has the ability to bootstrap from serial
16:22.24[g2]I"ve done it on the Cirrus boards and the Glomation board
16:23.14*** join/#oe katossi_uni (n=guillerm@linkwood.informatik.uni-duisburg.de)
16:24.07gremlin[it]work[g2] yes ... was one of the reason i don't bought it some months ago ...
16:24.59gremlin[it]workwell know that there is all time a way to reflash the bootloared is good ... but should be nice also to debug the board
16:29.16cyphunkI run bitbake -b on a .bb file, it creates the logs, I fix something and want to check again but now it doesnt create logs anymore
16:29.17cyphunkonly the first time
16:29.42cyphunkI deleted the entire tmp/work/<package> dir, deleted the sources, tried again... still doesnt create log, this time doesnt create tmp/work dir
16:29.47cyphunkI missing something
16:30.00gremlin[it]worktmp/stamps
16:30.23cyphunkyeup, thanks
16:30.27XorAcyphunk: easy way is to use bitbake -c clean to remove workdir and stamps
16:30.57cyphunkXorA: and this will only remove the workdir for the defined .bb, right?
16:31.05[g2]gremlin[it]work you may want to stop by #ep93xx and #openjtag
16:31.20XorAcyphunk: yes, it just cleans workdir and tmp/stamps/packagename*
16:31.29cyphunkXorA: thanks
16:32.01gremlin[it]workyup thanks [g2]
16:32.26*** join/#oe Timelord (n=TL@66.150.138.156)
16:33.27cyphunkXorA: I'm running it, is it supposed to "Handling BitBake files: | (0047/2800) [ 1 %]" before cleaning?
16:33.48hrw|workcu
16:34.15XorAcyphunk: you can use -b ../org.openembedded.dev/packages/spanner/spanner.bb to work with that single .bb file
16:34.28cyphunkokay, thanks
16:34.35XorAcyphunk: this is useful for developing bb's but it doesnt proces DEPENDS
16:34.42XorAcyphunk: so be careful
16:34.53cyphunknoted
16:36.07*** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl)
16:40.13gremlin[it]work[g2] there is a site about linux on ep93xx ?
16:44.34cyphunkthe package I am configuring (libupnp) has two subdirs/subpackages in the source which I need to `cd` into before running make.  What is the proper way to chdir?
16:44.50cyphunkcan I just override do_compile() and chdir before running $OEMAKE ?
16:45.06XorAcyphunk: I beleive that is ok
16:45.15cyphunkXorA: okay
16:45.17cyphunkthanks
16:45.24XorAcyphunk: or maybe -C command to make
16:45.53cyphunkXorA: I guess that wouldn't hurt.  not what the readme says (uses cd) but worth a try ;)
16:46.28XorAcyphunk: I lack finess when it comes to bb writing :-)
16:47.26cyphunkXorA: what's wrong with this IRC room... you should be chewing me out out not already knowing this shit ;)
16:47.42XorAcyphunk: we are the nice guys :-)
16:48.54*** join/#oe W8TVI (n=me@166.165.152.194)
16:50.32CosmicPenguinBut kudos to cyphunk for knowing how IRC normally works.. :)
16:50.36*** join/#oe aoe (n=aoe@tigerente.htu.tuwien.ac.at)
16:58.24*** join/#oe mndctrl (n=mind@81.167.1.2)
16:59.18mndctrlI've got some small test applications like "hello world" etc I want to cross compile... is bitbaking still the simplest way to go, or is there a simpler way? any docs on thats available?
16:59.47XorA|gonemndctrl: bitbake devshell is probably yhe easiest
17:06.47mndctrldevshell.. hmm, I'll look into it, tnx ;)
17:10.19cyphunkthe makefile for this package uses a $PREFIX internallaly.  There is no configure for the package so this somethign it expects the installer to set in the env.  
17:11.27cyphunkhow can I set an env var for oe_runmake
17:17.48*** join/#oe gremlin484 (n=gremlin4@ip68-13-173-187.om.om.cox.net)
17:19.18*** join/#oe olivier__ (n=olivier@mag77-1-82-238-13-91.fbx.proxad.net)
17:20.42cyphunkhow do I control the env var of the oe_runmake command?  I need to set a prefix during make (since there is no configure for the package)
17:21.29*** join/#oe reenoo (n=r@p5489E2C3.dip.t-dialin.net)
17:22.16reenooevening
17:22.23polihello reenoo
17:24.04reenoohi poli
17:24.18reenoo~seen treke
17:24.21ibottreke <n=ggilbert@69-175-35-85.ventca.adelphia.net> was last seen on IRC in channel #oe, 41d 17h 35m 24s ago, saying: 'http://zaurus.catstar.org/jmqt/index_e.html'.
17:24.31reenoo~seen ggilbert
17:24.33ibotggilbert <n=ggilbert@tinman.treke.net> was last seen on IRC in channel #kde, 31d 21h 53m 1s ago, saying: 'mdeand1: No I see it now. I didn't see delete on it this morning when I was searching :)'.
17:24.35johbrahmshrw|work: hi - where can I get hold of a OZ 3.5.4 test image? I'm not having any luck building my own with OE...
17:25.57*** join/#oe zecke (n=ich@88.134.3.107)
17:31.09*** join/#oe AvengerMoJo (n=alex@207.44.242.115)
17:33.16*** join/#oe pleemans (n=peter@d54C24BC0.access.telenet.be)
17:45.24CIA-403koen 07org.oe.dev * r74ba86f4... 10/conf/machine/ep93xx.conf: ep93xx: use correct serial device
17:48.37cyphunkduring do_install I get this error: "install: cannot create regular file `/usr/lib/libupnp.so.1.2.1': Permission denied"
17:48.53cyphunkerr, I mean, do_stage phase, not do install
17:49.03cyphunkany ideas?
17:49.04koenlooks like it doesn't obey DESTDIR
17:49.10*** join/#oe Timelord0 (n=TL@66.150.138.156)
17:49.12koenit tries to install to your host system
17:49.20cyphunkyeah
17:49.28cyphunkthere is no configure for the package
17:49.32cyphunkonly the makefile
17:49.37cyphunkit takes $PREFIX from the env
17:54.49cyphunkany ideas?  Can I define $PREFIX for do_stage or do_install or should I make a patch to be applied to the make file which statically defined PREFIX inside of it?
17:55.07cyphunk(I'm only affraid the latter solution would have adverse affects during image builds?)
17:56.11*** join/#oe alan|home (n=alan@ARouen-152-1-74-194.w86-192.abo.wanadoo.fr)
17:59.33*** join/#oe incinerator (n=incinera@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk)
18:05.42*** join/#oe Timelord (n=TL@66.150.138.156)
18:09.44*** join/#oe [lala_] (n=lala@p54B387DA.dip0.t-ipconnect.de)
18:11.13emtecyphunk, patch the makefile to make it behave
18:17.11*** join/#oe Crofton (n=balister@hc6521cb5.dhcp.vt.edu)
18:17.31*** join/#oe pH5 (n=ph5@vpn-128-35.uji.es)
18:17.41pH5hi
18:20.15emtehey
18:21.45zeckeRP: ping
18:23.18zeckepb_: hey
18:23.39zeckepb_: I have read that link (git and other SCMs) and I do not agree with most of keith is saying
18:25.18pb__zecke: ah.
18:25.33zeckepb__: do you have that link again?
18:25.44pb__let me look
18:25.46zeckepb__: I can't argue with the local support (I guess keith is living in portland)
18:26.24pb__http://lists.freedesktop.org/archives/xorg/2006-February/013113.html
18:26.25pb__that looks like it
18:26.35pb__yeah, indeed he is
18:26.48zecke1.) well kernel people are special :)
18:26.53pb__I guess you can argue with him at fosdem
18:27.17zecke2.) svn AFAIK will not modify existing files (well one text file saying which is 'HEAD')
18:27.35zecke3.) well I can't argue that one - but I'm sure we have svn devels in berlin...
18:28.00zecke4.) well cvs2svn converts everything :)
18:28.30zeckewell and he does not take security, merging and daily usage into account
18:30.09pb__right
18:30.12pb__okay, that's interesting
18:31.36zeckeI still get schocked when git asks me to do a merge
18:35.50polizecke: why?
18:36.08zeckepoli: because I need to google :}
18:36.26polimakes sense
18:36.40zeckepoli: maybe this is a gnu ism... but I need to do the hard time merging using
18:36.46zeckegit-ls-files --unmerged
18:36.52zeckeand git-cat-file blob
18:36.56zeckeand calling merge by hand
18:38.28koenzecke: keep in mind that git is only a distributed model of rcs
18:38.48koenzecke: and nobody uses rcs without cvs anymore
18:38.48polihey... taken by how linus and stallman love each other...  shouldn't be any gnuisms in git ;)
18:39.11zeckepoli: git log is not working on FBSD and OSX
18:39.36koenzecke: I wonder why
18:39.53koeno wait, I know: only the linux kernel uses git
18:40.00polilol
18:40.01zeckekoen: GNU date gets called :)
18:41.08shadowsyou raise a very important point
18:41.18shadowsthe fdo stuff is not linux-only
18:41.31poliLinus and Stallman hate each other?
18:41.37poliOh, that point...
18:41.39shadowsyet the 'git' tool depends on GNU programs that are traditionally only on linux distro OSes
18:42.17poliWTF? livia:/tmp# md5sum /dev/hdb
18:42.17polierror processing /dev/hdb: failed in buffer_read(fd): mdfile: Input/output error
18:42.18shadowsmaking it inappropriate to push onto developers of software that are used to developing on non-linux platforms
18:42.31shadowsERROR: Nothing provides runtime dependency xhost
18:42.33shadowserr?
18:43.03shadowsoh
18:43.05shadowsi have an error
18:43.11poliDo I have a bad cd?
18:43.59CIA-403koen 07org.oe.dev * r4812c9eb... 10/packages/linux/ep93xx-kernel_2.6.15.bb:
18:43.59CIA-4ep93xx-kernel: update to derevo3
18:43.59CIA-4* ethernet is working
18:43.59CIA-4* userspace reached with nfsroot
18:46.52zeckeshadows: well, that is keith's issue :)
18:47.38shadowsi think monotone is the best SCM i've seen
18:47.45shadowsthe speed issues are the problem
18:48.10zeckeshadows: the lua integration makes merging a bit easier (as it can use meld...kdiff3)
18:48.21zeckeshadows: but git is moving very fast
18:54.52CosmicPenguinand git is where the love is right now
18:57.19koenzecke: http://article.gmane.org/gmane.comp.version-control.monotone.devel/6110
18:59.17pb__later all
19:02.18*** join/#oe gremlin484 (n=gremlin4@ip68-13-173-187.om.om.cox.net)
19:03.22*** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl)
19:03.54*** join/#oe gremlin484 (n=gremlin4@ip68-13-173-187.om.om.cox.net)
19:04.46zeckepb__: later pal
19:05.30koenzecke: the monotone people seem genuinly interested in our needs
19:05.37koenmaybe we should have a dialog
19:06.23zeckeright, one should always have a dialogue
19:06.36*** join/#oe gremlin[it] (n=gremlin@88-149-150-99.f4.ngi.it)
19:07.13zeckekoen: it would be interesting to have a monotone 0.26 server available
19:07.28zecketo show people that it is way faster already (even if this new code is unoptimized)
19:07.34koenI could run on on dominion
19:07.49koens/on on/one on/
19:07.52zeckeand we should create static packages so people can test easily (we need the root dir rename one)
19:08.18zeckeI'm about to go to the gym, but I wrote a little test for bittest and I'm going to post the result soon
19:08.29koennice
19:08.29shadowskoen: i would help test a monotone 0.26 server
19:08.38shadowskoen: i hear the speed improvements are worth it
19:08.57koenshadows: about 7-8 times faster pull on an OE tree
19:09.11shadowsyeah.  that plus decent hardware = less pain
19:09.19koenand maybe more with another delta storage method
19:09.39zeckeshadows: on localhost a pull took only a couple of hours :} (Athlon XP 2600+) FBSD
19:09.48zeckeshadows: which is already better than a couple of days
19:10.14shadowszecke: IIRC when working with Gentoo, a pull took about an hour and a half via cvs
19:10.29shadowswhich was the pinnacle of achievement
19:10.29shadowsheh
19:10.46shadowsi'll bet they're still using CVS because it is the fastest
19:10.49zeckeit took 1:22m sys and user and I'm not sure if I need to add these values (output of time)
19:11.02shadowsah
19:11.40zeckeah okay
19:11.53zeckea pull took two hours (org.oe.dev)
19:12.17koenon what hardware?
19:12.26zeckeAthlon XP 2600+ 1.5GB ram
19:12.27koen0.25 takes ~8 hours on a dual opteron
19:17.18zeckeokay a pull on localhost with 0.25 was killed after taking more than 12hours :)
19:17.24zecke(I killed it)
19:17.35*** join/#oe zap (n=zap@217.170.93.196)
19:19.25hrw|work<PROTECTED>
19:24.45hrwhi
19:25.12hrwkoen: that mail about monotone is about undo/logdir things?
19:25.15koenhey hrw
19:25.19koenhrw: yes
19:25.28hrwmy work :)
19:25.32koen:)
19:26.09hrwi was discussing on #monotone when lacked monotone log dirname
19:26.29hrwI need more gettys on c7x0...
19:26.47hrwforgot to add some :(
19:26.58zeckeI think more than one Gettys (Jim) won't fit on your c7x0
19:27.16koenyeah, X is heavy
19:27.29hrwkoen: X is fluuf
19:27.55hrwand over 20 years old so it must be rahter obsolete now..
19:28.09hrw~lart c760 keyboard a bit
19:28.14zeckeSteve Jobs never liked it anyway
19:28.33hrwzecke: who liked Steve jobs...
19:29.03zeckehehe
19:29.07koenzecke: let me put on my black turtleneck and make some statements ;)
19:29.43hrwhow goes #monotone talk?
19:29.59koenI'm writing an email right now :)
19:30.25hrwto oe? or monotone-dev?
19:30.41hrwif 2nd then cc: me pls
19:34.01shadowshrw: updates are now happening to X11 :)
19:34.06shadowsXCB work is in place
19:34.55hrwshadows: nice - fdocvs thing?
19:35.33shadowsthe XCB is not included in my changes to fdocvs bb updates
19:35.58shadowsin simple words, XCB is newer, lighter, and replaces Xlib
19:36.12shadowsthere is a compatibility work called XCB/Xlib
19:36.36koenxcb is also more async, right?
19:36.45shadowsyes
19:36.59shadowsit is intended for desktop use also
19:37.03koenxcb was very hot 3 or 4 years ago
19:37.15shadowsthe old xcb work seems to be unrelated now
19:37.44hrwIll ignore it anyway
19:37.53hrwits .dev and its X
19:38.12shadowsyeah
19:38.41shadowstoday i am smoothing the patch for fdocvs-using builds in .dev
19:38.41*** join/#oe moa (n=cedric@LAubervilliers-151-11-32-8.w193-251.abo.wanadoo.fr)
19:39.05hrwkoen: Ill try to remove keylaunch tomorrow from images, push some oz 3.5.4 things and TAG it
19:39.20koennice
19:39.31hrwlet mortal kombat^W^Wopenzaurus building begins
19:39.33shadowskoen: do you want some bb's to lack the PR setting?
19:40.17koenshadows: it doesn't hurt
19:40.35koenbut if it's set to 'r0' you can leave it in
19:40.38shadowsmy first patch (the one you responded to on bug tracker) adds PR to all bb files, and for ones with PR already, bumps the revision
19:41.02shadowsi know, i will split that change out more
19:41.27shadowsshould i still use the changes to add "PR" setting?  i heard that -ALL- bb descriptions must have the PR setting
19:41.44koenbitbake sets it by default to r0
19:42.04shadowsokay
19:42.05hrwcu
19:42.20koenhrw|gone, zecke: http://rafb.net/paste/results/oTypnP40.html
19:42.32*** join/#oe Harvy (n=norm@80-193-172-141.stb.ubr05.pres.blueyonder.co.uk)
19:42.34koenany suggestions/additions before I press send?
19:43.10shadowsis there a feature that lets us only update the contents of the directory we're in?
19:43.14shadowsi don't know monotone too well
19:43.27shadowsi suppose that is not supported
19:45.43koenshadows: http://rafb.net/paste/results/QjSeRp41.html
19:46.15*** join/#oe _frank (n=user@84.92.70.37)
19:46.31shadowsyes there should be a sanity check for the merge tool
19:46.36shadowsi like that suggestion
19:47.11zeckekoen: I need to leave now :}
19:48.21*** join/#oe stevenh (n=lews@65.167.23.2)
19:48.31shadowswow
19:48.50shadowsJustinP was very clever in the work-around for gcc4 and the gtk-webcore builds
19:49.00JustinPshadows: was I now? ;-)
19:49.09JustinPshadows: surprised you didn't look at it when I committed it
19:49.56JustinPshadows: I even pasted it into the channel back then....
19:49.56shadowsnah, i just presumed your genius would save the day
19:49.56shadowsand moved on to the rest of my fixes
19:49.59JustinPheh
19:50.00JustinPok
19:50.08shadowsthat's really bloody clever, mate
19:50.20koengcc4 fixes?
19:50.29koenit didn't build this morning
19:50.32shadowskoen: gpe-image now builds with gcc4 as the cross-initial
19:50.40koenwith bitbake trunk and OE head
19:50.41JustinPwell....I took the general format from a webpage on sumulating ? : with python
19:51.27shadowskoen: bugs related to gcc4 as cross-initial and OE targets should be directed to me
19:51.31zeckeJustinP: only issue  I have no PREFERRED_CROSS set
19:51.45zeckeJustinP: I have a cset to 'fix' it pending so please do not do anything...
19:51.54koenshadows: http://rafb.net/paste/results/9E9BSU16.html
19:52.19shadowskoen: blame that on JustinP ;)
19:52.30shadowskoen: it works for me here
19:52.51shadowsi think you need to have that variable set though
19:53.03shadowsJustinP: does the  build system automagically define that var?
19:54.10zeckecya later
19:56.04*** join/#oe chewy (n=dieu@r2351064.cidc.net)
19:56.56shadowskoen: what is your distro set to?
19:57.26*** join/#oe W8TVI (n=me@166.165.159.187)
19:57.34shadowsi'm guessing angstrom or maemo
19:57.40koenshadows: angstrom-2006.9
19:57.43shadowsyes
19:57.52shadowsangstrom does not follow the behavior of the other distros
19:58.03shadowsjnc@baker:~/opensource/openzaurus/org.openembedded.dev$ grep -rn PREFERRED_VERSION_gcc-cross *
19:58.25shadowsfollow that and you'll see what  i mean;   what is the correct thing to follow?
20:00.40JustinPshadows: must not, no
20:01.14shadowswe must have a mechanism to say "this package will only build with x.y.z compiler"
20:11.26pb_shadows: that would be DEPENDS, I suppose.
20:11.46shadowspb_: can you explain more?  
20:12.11shadowsor give an example of where that is done
20:12.46pb_DEPENDS = "gcc-cross-3.4.4"
20:17.48shadowsJustinP: what do you think
20:18.39pb_or, alternatively, add an anonymous function that checks the compiler version and blows up if it isn't what you want.
20:18.49shadowsoh
20:19.08shadowshey, what arguments do you give to 'diff' tool?
20:19.17shadowsi've been using -bur but that blows up on Makefiles
20:19.43pb_uprN
20:20.48reenoohmm
20:21.03reenoowill PREFERRED_PROVIDER win over DEFAULT_PREFERENCE?
20:21.10pb_yes
20:21.31pb_DEFAULT_PREFERENCE is pretty weak, virtually anything will beat it
20:21.41reenoook, thanks
20:22.00pb_I think the bitbake manual might have some words about that, actually.
20:22.11pb_I certainly remember writng a description of how the resolution process works at one point.
20:25.25shadowshey all, what do you guys think about moving damageext and compositeext ... etc.  into packages/xlibs?
20:25.43shadowsthat is according to where they get their files from SCM
20:25.51shadowsi.e. xlibs fdo cvs
20:26.19shadowspackages/gtk-webcore and packages/cairo currently do this
20:26.41pb_sounds like a reasonable plan to me
20:26.55shadowsdoes the directory name (damageext) factor into any of the variables?
20:26.59pb_no
20:27.05pb_it's just for convenience
20:27.07shadowsokay so, that means just the name of the bb
20:27.43shadowsin Gentoo we had a system where the directory name and capitolization would translate to a variable that could be used in the build description
20:27.52shadowsmoving directories around like that would pooch the build
20:28.03shadowsyou're saying it's just for convenience, is that 100% sure?
20:28.27pb_yeah.  you could (approximately) do "mv */* opie-powerchord/" if you wanted, and everything would still work just fine.
20:28.38shadowsexcellent
20:28.41pb_that actual command would probably fail because all the "files" directories would collide, but you get the general idea
20:28.45shadowsi'll add that to my list of changesets to make
20:28.55shadowsoh hmm
20:28.57shadowsgood point
20:29.19pb_plus, obviously, having everything inside an opie-powerchord directory would be a dim plan in general.
20:29.24CIA-403rw 07org.oe.dev * r0de420be... 10/packages/gtk-webcore/ (4 files):
20:29.24CIA-4gtk-webcore: fix parse errors in 20060212 snapshots.
20:29.24CIA-4<PROTECTED>
20:29.25CIA-4<PROTECTED>
20:30.07reenoopb_: yah, sorry. guess I should read a current version of it one of these days.
20:30.19reenooshadows: that wasn't directed at you
20:30.36shadowsreenoo: it only breaks if the variable is not set
20:30.43shadowsi had no idea it was not set in Angstrom and maemo
20:31.03shadowsi only checked familiar and openzaurus, the more popular targets. my mistake
20:31.27reenooit doesn't really matter where it's set or not. it should never blow up.
20:31.36shadowstrue
20:32.00shadowsthe no-threadsafe-statics flag only exists in gcc4 though
20:32.47shadowsi can't test for gcc3, since gcc3 doesn't exactly output sane code on my machine (amd64)
20:40.19CIA-403koen 07org.oe.dev * ref0ce499... 10/packages/linux/ep93xx-kernel_2.6.15.bb:
20:40.19CIA-4ep93xx-kernel: update to derevo4
20:40.19CIA-4* fixes reboot
20:50.48*** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby)
20:51.05shadowsugh
20:51.30shadowsinsane quantity of files affected by the cvs URL
20:52.31koenshadows: that's why we usually put a magic var in bitbake.conf
20:52.39pb_shadows: delete 'em all.  let them eat tarballs.
20:52.52shadowsi'm centralizing the vars
20:52.58shadowsit's just a workaround for now
20:53.13*** part/#oe law_ (n=_law_@213.173.86.202)
20:53.17shadowsbut it will allow us to easily grok for the files that need to be changed, when we have a proper fix
20:53.20shadowsunlike now
20:53.47shadowsbtw i did a full gpe-image build with the previous changeset
20:53.48*** join/#oe chouimat (n=dieu@kde/developer/chouinard)
20:53.49shadowsit worked fine
20:54.01shadowsso these changes i'm smoothing out should also inherently work
20:54.31pb_ah, it's always nice when changes are inherently correct.
20:54.34pb_zero defects!
20:54.44shadowsheh
20:55.05shadowswell there was a tiny bug in the first changeset, and it was easy to fix.   i'm going to have to update the bbclass files i posted
20:55.16shadowsone of them (xorg.bbclass) is -obviously- wrong
20:55.33shadowsother than that, it built fine.
20:55.45shadowsin fact, when the build broke, it was obvious where to fix the problem
20:55.49shadows=)
21:03.40shadowsi guess this should instead all be in maybe some freedesktopcvs bbclass
21:03.42shadowsi don't know
21:04.01shadowsthe changes i'm making now will nontheless make it easier to go to a better solution later
21:04.05shadowsso i'm not worried about it now
21:05.33CIA-403rw 07org.oe.dev * r21f1a517... 10/ (61 files in 56 dirs): various packages and bitbake.conf: introduce FREEDESKTOP_CVS and make use of it.
21:05.42shadowsgod dammit
21:05.50shadowshere i am making all these changes
21:06.16reenoowell, here a sed script did all the work
21:06.43shadowsdid you do a search on 'pdx' or something?
21:08.55shadowshttp://bugs.treke.net/show_bug.cgi?id=706
21:09.34RPshadows: I've back moving all the xlibs into one directory - I've been meaning to ask about doing that
21:10.01shadowsRP: yeah, it makes sense IMO to have them in one dir (if that's the kind of thing that is okay to do)
21:10.19shadowsespecially if they are from the same specific CVS branch
21:10.33RPshadows: It was once frowned upon but IMO the current directory is unmanagable
21:10.47RP<PROTECTED>
21:10.50shadowsmmhm
21:11.10shadowsi have only the gentoo and debian ways to compare with
21:11.28shadowsdebian is, you make several packages out of a single build description
21:11.32shadowsi don't think that follows what we're doing at all
21:11.54shadowsgentoo is, you have "sections" and a seperate directory for each package
21:12.00shadowswe don't have sections
21:12.07RPHere its just convinience. I think it makes logical sense to combine them though
21:12.09shadowsnow would be a good time to think about whether we want sections
21:12.25*** join/#oe Geo_KM (n=keith@ppp47-111.lns2.syd6.internode.on.net)
21:12.48RPsections feel wrong in OE somwhow...
21:12.54CIA-403eFfeM 07org.oe.dev * r20f293e2... 10/packages/spca5xx/ (spca5xx-20060202/Makefile.patch spca5xx_20060202.bb): spca5xx: added release 20060202 (on request, builds fine, cannot test this as I do not have this cam)
21:13.04shadowsagreed
21:14.57shadowshrmmm multiple heads
21:15.27shadowsis that usually happening while things are synchronizing accross servers?
21:15.47reenoono, that happens when someone doesn't merge
21:16.08shadowsoh
21:16.11shadowscould you merge?
21:17.18shadowsactually i think it's syncing now
21:17.39shadowsit does appear that the tree is unmerged, when people make big commits that take a while to propogate
21:17.51reenoono
21:18.00shadowsno?
21:18.05reenoono
21:18.13*** join/#oe xep (i=misha@dsl027-176-045.sfo1.dsl.speakeasy.net)
21:18.24koenit happens when people make commits using the same ancestor
21:18.30shadowsoh hmm
21:18.44shadowsso after pushing a change, you'd have to pull again, then merge
21:18.46shadowsand push again?
21:18.49polishadows: it is actually something monotone considers "natural"
21:18.55poliBut it is damn annoying!
21:18.58shadowsheh
21:19.26poliMakes sense when you think your changes won't be spolied by an update... but...
21:19.49CIA-403rw 07org.oe.dev * r517c224b... 10/packages/ (10 files in 5 dirs): more fd.o hosted packages: use FREEDESKTOP_CVS.
21:21.22shadowsreenoo: you borked the useage of the xlibs bbclass, i think
21:21.33shadowsi.e. made it depreciated
21:21.45shadowsthere was an xlibs bbclass before that defined the FDO CVS server
21:21.58shadowsplease have a look at that, and also comment on bug 706
21:22.44reenoonah, that's a different story
21:23.13reenooalthough it should use FREEDESKTOP_CVS too, obviously
21:24.46*** join/#oe greentux (n=m@195.227.105.180)
21:29.17CIA-403rw 07org.oe.dev * r50ca4355... 10/classes/xlibs.bbclass: xlibs.bbclass: use FREEDESKTOP_CVS as well. Thanks to Eric Shattow for spotting.
21:30.21shadowsstick a fork in my eye ;)
21:30.33shadowsokay well, back to what i was working on a few days ago
21:32.06*** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby)
21:35.11shadowshey is anyone looking for a Sharp serial cable?
21:35.25CIA-403florian 07org.oe.oz354fam083 * rea987265... 10/packages/gpe-conf/ (files/fixsegfault.patch gpe-conf_0.1.30.bb): gpe-conf: Add release 0.1.30 and a patch to fix a remaining issue.
21:35.26shadowsthere is one being sold (with SL-5500 attached ;)
21:35.29CIA-403florian 07org.oe.oz354fam083 * r4557c88c... 10/conf/distro/preferred-gpe-versions-2.7.inc: preferred-gpe-versions-2.7: Use gpe-conf 0.1.30 including several bugfixes.
21:35.38RPshadows: Which country?
21:35.41shadowsUSA i think
21:36.02RPIf it was the UK I might have been interested :)
21:36.03shadowsi bought one from a china seller, and still have not received it
21:36.11shadowsit's been a couple of weeks now
21:36.16RP:-/
21:36.17shadowsi think that i may have lost out on $50usd
21:36.48pb_heh.  it's probably just on the infamous slow boat from china.
21:37.07shadowsthat is true
21:37.21CosmicPenguinThats a popular ship
21:37.25shadowswhen i did sales representation, for mfg companies, the "boat from china" was never on time
21:37.51shadowsin fact, if it got to the right destination on time, there was always some reason for it to be turned around and sent back to china
21:37.58shadowswhere it would be sent back again
21:38.01shadowsand take twice as long
21:38.20shadowseBay #5867800043
21:38.36shadowsalso includes a camera attachment
21:38.58shadowsRP: are you interested in the camera?
21:39.13shadowsi may buy this and donate it to a dev if they want/need it for better support
21:39.19RPshadows: The original Sharp one?
21:39.22shadowsyes
21:40.04RPshadows: Its a binary only driver and not particularly good quality now - I've not considered it worth any development effort...
21:41.00shadowsah
21:43.26shadowsi'm looking around to find an addressbook PDA for my grandfather, replacing his old ZR series organizer
21:43.32CIA-403florian 07org.oe.dev * r98e42d2d... 10/packages/gpe-conf/ (files/fixsegfault.patch gpe-conf_0.1.30.bb): gpe-conf: Add patch to fix segfault in 0.1.30.
21:43.42shadowsthe Palm units have no keyboard and are _very_ difficult to use for an elderly person
21:44.08shadowsi think that the text on the zaurii looks too small
21:44.15shadowssuggestions?
21:44.22pb_I guess you can make the text on the Z as big as you want
21:44.26shadowshmm
21:44.42shadowsthat's true, the screens and keyboards are smaller than the ZR series though
21:44.54shadowsi'm concerned about the text on the keys being way too small
21:45.31pb_if all he wants is addressbook, you might try something like one of the old Psion units, a Revo or something.  I don't know if they're still made, but you can probably find them on ebay.
21:51.45shadowsinteresting
21:51.51shadowsthose look perfect in form
21:54.45koen|tvreenoo: that commit to webcore fixed the gcc4 build, thanks
21:56.56*** join/#oe incinerator (n=incinera@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk)
21:57.45reenookoen|tv: np, I just fixed the parse error. shadow did the gcc4 related part.
21:59.51emteshadows, if all you want is an address book buy a ROX
22:00.01emteor is it REX
22:00.04shadowsyeah, just an addressbook
22:00.05emteone or the other
22:00.10koen|tvemte: REX
22:00.43emtecheap device originally made to clipon pagers etc
22:00.45shadowsfor the old man, he needs something with a large font that's easy to work;  not to say that he isn't capable of complicated computer functions, it's just not worth his time to be mucking about with
22:01.07shadowshis daughter gives him a Palm IIIc
22:01.13shadowsi just about died laughing at that
22:01.24shadowswhat is he going to do with a freaking Palm pilot?
22:01.59shadowsi barely do anything interesting with *mine*, and i've still got my vision and plenty of time to mess with configuration conflicts
22:03.40emtehttp://cgi.ebay.com/Almost-new-Xircom-REX-6000-Micro-PDA-PCMCIA-NR_W0QQitemZ5868290404QQcategoryZ38331QQrdZ1QQcmdZViewItem
22:03.50emteshadows, a basic REX device
22:04.23emtethats actually the nicest REX i've come across ....
22:05.29shadowsit's kind of tiny
22:05.37shadowsare those easy to read?
22:05.42emteyup thats what makes it nice
22:05.49emtefits in your pocket
22:05.55shadowsoh
22:06.11shadowsit does look nice, i'm thinking about something with a very large screen though, maybe wide format
22:06.34emteremember if you expect him to use it he has to be comfortable carying it arround
22:06.44shadowshe's probably not going around town with it
22:06.55shadowsif he is, it's going to live in a briefcase
22:07.15shadowsone of our buddies has that sort of REX device, a little CF format card
22:07.16emtehttp://www.the-gadgeteer.com/review/rex_6000_review
22:07.19shadowsit was great until it died
22:08.17emtereview suggests finding a REX 5000
22:08.41emteoh wait thats backwards i think ..
22:10.06emtehttp://www.epinions.com/content_11730521732
22:11.28emteinteresting ...
22:11.32emte<PROTECTED>
22:12.23emtehmm looks like the xzire
22:12.29emtezire*
22:12.32emteanyway off to physio
22:12.46shadows:)
22:12.55shadowsthe Psion 5 looks about right
22:13.07shadowsit runs on AA batteries, has a decent keyboard
22:13.28emtebuy him a sidekick :P
22:36.40*** join/#oe zecke (n=ich@88.134.3.107)
22:36.54zeckere
22:37.01RPhi zecke
22:37.50zeckeRP: I have a list of native packages RDEPENDING on non native versions
22:38.11zeckeRP: I don't want to teach bitbake about native packages
22:38.22zeckeRP: I think the proper fix is to change our meta data
22:38.36RPzecke: The meta data is wrong at the moment, yes
22:39.00RPzecke: The question is whether we set RDEPENDS="" or set it to native packages
22:39.33zeckeRP: it is funny :)
22:39.36RPOne way around the ASSUME_PROVIDED problem might be to agree that ASSUME_PROVIDED lists both depends and rdepends?
22:39.42zeckeRP: quilt-native needs patch-native
22:40.03zeckeRP: and patch native needs 'patch' (as it can't use quilt) available...
22:40.19zeckeRP: and if you require it, it shouldn't be in a RDEPEND :)
22:40.52RPzecke: Do you require it at build time or runtime?
22:41.09RPzecke: We're always going to require some ASSUME_PROVIDED packages
22:41.25zeckeRP: for quilt-native, we manually use 'patch' to patch quilt
22:41.56zeckeRP: well, I think patch and gcc are cases where you simply 'require' them
22:42.08RPAdding patch-native to the default assume_provided is safe IMO
22:42.45RPIt would be nice if the default ASSUME_PROVIDED line was the same as our list of prerequisite software
22:43.27RPzecke: We also have an explode_deps bug hanging around: See part of http://www.rpsys.net/openzaurus/temp/bitbake_git-r1.patch
22:44.08zeckeRP: (not that I understand the explode bug) but we should fix the copy in OE as well
22:44.40RPzecke: Think of a version of the form (>= 2.3.4) - the space being critical
22:44.47RPzecke: What do you think about allowing both providers and runtime providers in ASSUME_PROVIDED?
22:45.29RPI agree we need to check the copy of that function in OE
22:47.41zeckeRP: http://pastebin.ca/42390
22:49.09zeckeI'm a bit exhausted from gym, so give me some minutes to recover (before I stress my multitasking skill again)
22:50.24RPzecke: I think I see a flaw in your check as you might have only checked RDEPENDS, not RDEPENDS_${PN}
22:50.37RPzecke: but ignore me for a few minutes - I also have something I need to finish
22:50.58zeckeRP: you can check the test soon :)
22:53.30*** join/#oe Timelord (n=TL@4.78.4.43)
22:55.44zeckeRP: http://svn.berlios.de/viewcvs/bitbake/trunk/bitbake_qa/modules/depends_checker/depends.py?rev=368&view=markup
22:55.58zeckeRP: it has other bugs but it looks at RDEPENDS_${PN} :)
22:56.29zeckeokay I will get some food now
22:57.37RPzecke: when you get back I have some comments ;-)
22:57.40CoreDump|homehi
22:58.42CoreDump|homehrw|gone: yes, I'm planning to do that. But I need to verify kernel 2.4 functionality first
22:58.56RPhi CoreDump|home
22:59.29CoreDump|homehello RP
22:59.39zeckeI have not left
23:00.30RPzecke: Basically, I dislike the idea of using PN as an override as some packages probably end up with values in both RDEPENDS and RDEPENDS_${PN}
23:00.42RPzecke: and you should be using explode_deps ;-)
23:01.29zecke(you have commit access) :)
23:01.57RPtrue. I have a job to finish, then I might use it :)
23:02.21zeckeRP: for the explode_deps thing, could you send me a list of strings and how they should end up :)
23:03.11RPzecke: xxx (xx anything in brackets) should become simply xxx as far as bitbake is concerned
23:03.54JustinPshadows: I don't know what to think
23:04.05RPzecke: Note the version in OE does care about the version string. the one in bitbake does not
23:04.28lamikrI have forget how to get the gpe-image to configure /etc/modules correctly in first boot. I tried adding things like following kind of things to board-h6300.conf but when I booted first time, the /etc/modules was empty.
23:04.30JustinPRP: I don't suppose you've looked at the corgi_ssp stuff? I'm going to try to look at it now....
23:04.34lamikrmodule_autoload_omapts = "omapts"
23:05.34pb_that sounds about right.  did you rebuild the kernel afterwards?
23:06.03zeckemy slive of bread should be toasted by now
23:06.08zeckeslice even
23:06.14pb_thanks for the bulletin
23:07.31lamikrpb_: I build the whole gpe-image from scratch. It failed couple of times and I needed to edit the machine-conf but those module_autoload= lines were there unmodified since the beginning.
23:07.48pb_lamikr: what do you have in /etc/modules.d/?
23:08.11zeckepb_: you are welcome :)
23:08.14zeckepb_: do you want some as well?
23:08.20RPJustinP: The good/bad news is that the max1111 didn't use the bit bang code so its not that at fault (the lcd used that)
23:08.22pb_zecke: no thanks, I just ate dinner
23:08.26*** join/#oe ruied (n=ruied@213.22.166.23)
23:08.34zeckeyou are lucky :)
23:09.05zeckeRP: I have one question: if I remove the BUILD_ALL_DEPS from native.bbclass and build the opie-image
23:09.13lamikrpb_: At least after boot I do not have /etc/modules.d at all.
23:09.24zeckethe RDEPENDS get build anyway
23:09.35CIA-403rw 07org.oe.dev * rd7c8c3fb... 10/packages/fontconfig/fontconfig_2.2.95.bb: fontconfig: fix SRC_URI. part of a patch submitted by Eric Shattow in Bug #706
23:09.57pb_lamikr: oh, sorry, it's /etc/modutils/
23:10.00RPzecke: Yes. I'm not sure that's a problem?
23:10.05CosmicPenguinargh
23:10.12JustinPRP: well that's good news of a kind. I'll look into the command thing...
23:10.40RPJustinP: I have seen the max1111 give weird readings for the power management code so if there was a bug in the max1111 code, I'd like to find it
23:10.54RPJustinP:  but that would be attributed to other things...
23:10.54zeckeRP: this is due the opie-image.bb BUILD_ALL_DEPS right?
23:11.00RPs/would/could
23:11.27RPzecke: anything that inherits the image .bbclass, yes
23:11.33CosmicPenguinnote to self - read the bb before building it
23:11.53pb_CosmicPenguin: ah, you accidentally bitbaked r00tk1t.bb?
23:12.12CosmicPenguinheh
23:12.40pb_I hate it when that happens
23:12.58JustinPRP: hmmm...
23:13.06*** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com)
23:13.10lamikrpb_: I do not have even that... Should I add "modutils" somewhere to the h6300-conf. Here is the current "uncommitted" version of h6300.conf I have tried to create. http://pastebin.ca/42407
23:13.28RPJustinP: It shouldn't be too difficult to establish my functions are equivalent to sharp's.
23:13.47RPJustinP:  You could also try copying sharp's functions into the driver to compare their readings
23:13.51pb_lamikr: is kernel-module-omapts actually in your image?  If so, what files does it contain?
23:14.12RPJustinP: see arch/arm/mach-pxa/pxa_ssp.c for them
23:14.35JustinPRP: ah, thanks (was just grepping)
23:14.46zeckeRP: do we want native packages to have RDEPENDS at all?
23:16.10RPzecke: I still say yes and that we should have ASSUME_PROVIDED handling the ones we don't want built
23:16.52lamikrpb_: Not 100 % what you mean but I have omapts driver module under kernel. Exact location is "/ipaq_rootfs/lib/modules/2.6.16-rc3-omap1-h6300/kernel/drivers/input/touchscreen/omap/omapts.ko"
23:16.55zeckethis means a patch-native.bb may not use 'patch'?
23:17.24pb_lamikr: ah, do you mean that you have defeated the kernel module splitting?
23:17.28RPzecke: Obviously there are some things that must be provided by the host system
23:17.29pb_if so, yeah, that will also break autoloading
23:18.17RPzecke: As an argument against myself, python-native is a tricky one. We can't ASSUME_PROVIDED it as python itself needs it to build and yet python is a prerequisite of bitbake/oe
23:18.39lamikrpb_: Not sure... I have just selected in my .config that omapts is build as a module.
23:18.59pb_lamikr: well, which package contains the .ko file you mentioned?
23:19.04zeckeRP: this might be a good start and documenting the REQUIREMENTS
23:19.39zeckedamn it
23:19.48RPzecke: I did see it having that advantage :)
23:20.18zeckewhen  was gtk-webcore touched?
23:21.18lamikrpb_: I have not tried to open, but tmp/deploy/ipk has "kernel-module-omapts-2.6_2.6.14.3-r0_h6300.ipk"
23:21.29JustinPRP: well, the MAX1111 defines seem to be equivalent
23:22.21pb_lamikr: what files are inside that package?
23:24.34zeckereenoo|afk: *sorry*
23:25.26CIA-403freyther 07org.oe.dev * raa1b3639... 10/packages/gtk-webcore/ (4 files):
23:25.26CIA-4gtk-webcore:
23:25.26CIA-4<PROTECTED>
23:25.26CIA-4<PROTECTED>
23:25.30CIA-403freyther 07org.oe.dev * r623eed7c... 10/classes/tinderclient.bbclass:
23:25.30CIA-4classes/tinderclient.bbclass:
23:25.30CIA-4<PROTECTED>
23:25.31CIA-4<PROTECTED>
23:25.33CIA-4<PROTECTED>
23:26.51zeckeRP: should we add a method
23:27.04zeckethat automatically add '-native' to RDEPENDS
23:27.28lamikrpb_: It has ./lib/modules/2.6.14.3-omap1-h6300/kernel/drivers/input/touchscreen/omap/omapts.ko,  /DEBIAN/control, postinst and postmdr files and /etc/modutils/omapts file
23:27.40pb_okay
23:27.41zeckeRDEPENDS = "$@{oe.create_depends(['m4', 'autoconf'],d)}
23:27.56pb_lamikr: so, you need to figure out why that /etc/modules/omapts is not showing up in your installed system
23:28.40RPzecke: Given most bb files include their non-native counterparts, it would be even better if we could just translate that...
23:28.52RPtranslate their RDEPENDS
23:29.07zeckethis requires to do the 'include' before the inherit
23:29.45zeckereenoo|afk: I will disapprove my merge (due the meld error...) once viewmtn is available
23:30.01CosmicPenguin~lart udev
23:30.18RPzecke: I know, I'm not sure its technically possible :-/
23:30.50pb_zecke: I don't think the order should matter much.  You can use a function.
23:31.47zeckepb_: like RDEPENDS := "${@fix_up(d)}"?
23:32.31pb_no, that would indeed have the ordering problem.  more like:
23:32.34zeckeRP: one good thing about 'patch' is. I have BSD patch and a GNU patch works way better with quilt
23:33.30pb_python __anonymous () { bb.data.setVar("RDEPENDS", bb.zecke.mungeRdepends(), d) }
23:33.31pb_kind of thing
23:34.06zeckepb_: do you know when __anonymous is evaluated?
23:34.11pb_yes
23:34.22lamikrpb_: It is not the only missing driver... It seems that by default I have only one driver installed under /lib/modules/kernel/2.6.14.3. It is kernelt/net/ipv4/netfiler/ip_tables.ko... Strange thing is that I have not specified anything ip_tables related to http://pastebin.ca/42407
23:34.56zeckepb_: so enligthen me please :)
23:35.03pb_zecke: at the end of parsing
23:35.34zeckepb_: I had hoped for that. Now let us find out if it is still true
23:36.52zecke(I think it is)
23:38.11pb_lamikr: so you have some modules for 2.6.14.3 and some for 2.6.16-rc3?  that can't be good.
23:38.28pb_presumably you are only running one kernel at any one time
23:39.41pb_anyway, this doesn't sound like an autoloading problem so much as the driver just plain being not installed.
23:39.50lamikrpb_: Sorry, I had installed the 2.6.16 modules afterwards by hand to rootfs. But oe build 2.6.14.3 kernel and put only this ip_tables.ko driver to gpe-image.tar.bz2
23:40.57pb_okay.  sounds like you need to add the modules you want to ${HANDHELD_MODULES} or whatever your equivalent to that is.
23:41.02lamikrIs this correct in my machine-conf:
23:41.03lamikrBOOTSTRAP_EXTRA_RDEPENDS += "${@linux_module_packages('${H6300_MODULES}', d)}
23:41.16pb_looks about right, yeah
23:41.24pb_what's ${H6300_MODULES}?
23:41.43lamikr#
23:41.44lamikrH6300_MODULES = "omapts i2c-omap pca9535 omap-keypad nfs \
23:41.45pb_zecke: let's hope it still is
23:41.46lamikr#
23:41.48lamikrbluetooth rfcomm bnep l2cap hci_uart h6300_bt"
23:42.29pb_that looks ok
23:42.29pb_what are the dependencies on the generated task-bootstrap.ipk?
23:42.35lamikrthey are in: http://pastebin.ca/42407
23:43.16pb_eh, that looks like your MACHINE.conf or something
23:43.28pb_are you sure that is the right pastebin url?
23:45.16lamikrpb_: I thought you meant that. How can I check the task-bootstrap.ipk dependencies?
23:45.32pb_use "dpkg-deb -I", or "ipkg status"
23:47.46lamikrpb_: Sorry I can not check it anymore. I stupidly deleted my tmp dir as I planned to do new build attempt from scratch...
23:51.30lamikrpb_: But I dound my taksbootstap.control file from rootfs that contains dependencies: it is in http://pastebin.ca/42425
23:57.08lamikrand it seems that for some reason it does not list kernel modules as a dependencies...
23:58.30zeckeRP: the automatic replacing won't work
23:58.50zeckee.g. foo-common is okay in RDEPENDS
23:59.26RPzecke: ok, we'll jsut have to go though and set the RDEPENDS correctly then I guess
23:59.33zeckejava-virtual-machine should be virtual/java-machine-native
23:59.57RPzecke: Did you have any thoughts on whether allowing ASSUME_PROVIDED to cover both types of depends was good/bad?

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.