00:02.34 | pb_ | mm, that is unfortunate |
00:05.44 | njs | so is "correct" even well-defined in this case? :-) |
00:06.53 | reenoo | yes |
00:07.19 | *** join/#oe _guillermo (n=guillerm@dslb-084-062-132-090.pools.arcor-ip.net) |
00:07.47 | reenoo | a solution is correct if the set of it and the expected answer is first order consistent |
00:08.42 | reenoo | checking whether it is FO con is unfortunately only semi-decidable |
00:09.20 | reenoo | and 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.46 | njs | but you could demonstrate such a proof, if only the bot would let you? :-) |
00:11.17 | Harvy | hi 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.45 | reenoo | njs: if I had the expected solution, probably yes. (not manually though, but with a semi-automatic prover) |
00:13.15 | njs | *sigh* I want to take classes where this kind of problem arises :-) |
00:14.02 | reenoo | heh. take classes on logic and you will run into this |
00:14.28 | reenoo | or maybe advanced theoretical CS |
00:14.52 | njs | the class on logic I took was all old-school pencil-and-paper-and-chalk |
00:15.04 | njs | and now I don't have time to take math classes anymore :-( |
00:15.23 | Harvy | from what I have seen on the site the bb files are wrong.. or maby me (ps any body see me) |
00:15.39 | njs | Harvy: see you, but I'm clueless, sorry. |
00:16.21 | *** join/#oe rwhitby-away (n=rwhitby@nslu2-linux/rwhitby) |
00:16.25 | reenoo | Harvy: cairo is moving to git, I believe. and anoncvs is being moved around on fd.o |
00:17.01 | Harvy | cheers 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.25 | Harvy | i have seen the change to git |
00:18.04 | reenoo | njs: 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.28 | Harvy | but the cvs access is pserver:anoncvs@cvs.ca |
00:20.38 | Harvy | I can dragg ALL the files down by hand to my sources dir but would prefer a working setup |
00:21.07 | Harvy | any developers on at the moment? |
00:22.03 | njs | reenoo: 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.51 | shadows | Harvy: i don't have commit access, or it would have been fixed |
00:43.29 | Harvy | if you could let somebody who does it would help |
00:43.52 | Harvy | just trying to do a build from the start |
00:44.11 | emte | why change part of the files if the rest will break tomorrow? |
00:44.16 | Harvy | cheers dude |
00:44.34 | emte | you could just use the other repo ... if it still exists |
00:44.51 | Harvy | what other repo |
00:45.21 | emte | treke's |
00:46.19 | Harvy | surely a rc should build tho |
00:47.08 | emte | you make false assumptions |
00:47.32 | emte | we have no control over other projects sources or what they do with thier source trees |
00:48.46 | Harvy | well the inital download is from the oe server why is it not there anymore |
00:49.01 | emte | you have the wrong ip |
00:49.10 | emte | dns currently does not work |
00:49.52 | Harvy | dns for oe... is wrong |
00:50.01 | shadows | what happened with openzaurus.org expiring? |
00:50.10 | shadows | is that project dead (in favor of Angstrom) ? |
00:50.36 | emte | what does the mailing lists say? |
00:50.49 | Harvy | what is the ip then |
00:53.43 | emte | through* |
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.43 | emte | hmm |
01:04.45 | Harvy | going to have to sign off soon because I have work tommrow UK but will log cheers |
01:04.56 | emte | oesources.org works for me now |
01:06.02 | emte | 192.216.230.225 |
01:07.06 | Harvy | i will give it a try tommrow ...ttfn |
01:07.13 | emte | k |
01:10.18 | emte | and the play by play after |
01:10.23 | *** join/#oe gremlin484 (n=gremlin4@ip68-13-173-187.om.om.cox.net) |
01:23.27 | emte | i think the 2.6 kernel has some serious bloat issues ... |
01:23.43 | shadows | are you on amd64? |
01:23.58 | shadows | what do you mean bloat issues |
01:24.02 | emte | i am talking about jsut unpacking it |
01:24.10 | emte | /dev/hdc1 111G 105G 0 100% /backupfiles |
01:24.19 | emte | build$ rm -Rf tmp/work/h3600-linux/handhelds-sa-2.6-2.6.12-hh0+cvs20060219-r0 |
01:24.31 | emte | /dev/hdc1 111G 93G 13G 89% /backupfiles |
01:24.44 | emte | takes up 13Gb of room |
01:24.54 | shadows | with the *.o yeah |
01:25.06 | emte | no, this is uncompiled |
01:25.11 | shadows | source code itself is not so bad, considering it has support for a bazillion targets |
01:25.16 | shadows | erhM? |
01:25.23 | emte | it never made it past ./configure |
01:26.23 | shadows | the 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.09 | emte | i just pulled the source tar out of /sources and am unpacking by hand |
01:27.22 | emte | i'll do a du -h and see what i get |
01:27.49 | shadows | remember if you have any sort of broken filesystem like reiserfs, 'du' will be incorrect |
01:29.36 | Harvy | reiseerfs is not broken |
01:29.59 | emte | lol |
01:30.03 | emte | i use XFS |
01:30.15 | emte | 283M kernel26 |
01:30.29 | Harvy | xfs is painful |
01:30.34 | emte | looks liek i generated 13Gb of garbage in taht compile loop |
01:30.44 | emte | i trust it far more than reiser |
01:30.52 | shadows | XFS is excellent if you have no hardware or software or power problems |
01:31.05 | shadows | and the moon is in the correct phase |
01:31.15 | shadows | with god herself smiling on you |
01:31.17 | emte | i've never had an issue with XFS in 5 yrs |
01:31.41 | emte | cd kernel26 |
01:32.15 | Harvy | you have never had an un panned shutdown in 5 years |
01:32.25 | emte | sure i have |
01:32.40 | emte | living on an island we have a couple powerouts every year |
01:32.46 | Harvy | and xfs was ok |
01:32.49 | emte | yup |
01:33.26 | Harvy | you got lucky have yu tried fiery os |
01:33.30 | emte | rieser was unrecoverable and ext3 ... lucky it suports ext2 mode |
01:34.00 | emte | fiery os, no |
01:34.30 | chouimat|TV | emte: I never had any problem with reiserfs ... and so far reiser4 was the best I tested |
01:34.34 | Harvy | never had aproblem with reisier |
01:34.52 | Harvy | fier rons on photocopiers |
01:35.01 | emte | i perfer my data being recoverable |
01:35.13 | emte | Harvy, oh wait |
01:35.24 | emte | you mean Fiery ... the RIP server |
01:35.30 | emte | yeah i've used it |
01:35.38 | emte | highend printing applications |
01:36.05 | emte | more from a user perspective, never messed with it |
01:36.24 | Harvy | and if it dies so does the HW |
01:36.32 | chouimat|TV | emte: recoverable?? it was I have a huge tape backup system ;) |
01:36.38 | chouimat|TV | s/was/why |
01:36.40 | emte | lol |
01:37.04 | Harvy | rip is right |
01:37.18 | *** join/#oe AvengerMoJo (n=alex@207.44.242.115) |
01:37.31 | Harvy | rest in peaces |
01:37.49 | emte | rip as in raster image processing ... lol |
01:38.18 | emte | firey is great if your trying to print a 300MB+ image |
01:38.45 | Harvy | emte: ttfn thnks for the help |
01:40.14 | emte | np |
01:40.15 | emte | brb food |
01:43.12 | *** join/#oe ai2097 (n=ai2097@pdpc/supporter/active/ai2097) |
01:55.27 | ai2097 | Is 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.48 | emte | ipag definatly needs some love on the client side |
02:03.53 | emte | ipkg* |
02:04.37 | ai2097 | Well, I guess another question would be, is ipkg actually intended for updating live/on-line systems? |
02:05.11 | emte | yes |
02:06.05 | emte | http://handhelds.org/moin/moin.cgi/Ipkg |
02:07.55 | shadows | should i be using the xlibs.bbclass directly? |
02:08.16 | ai2097 | emte: Thanks. |
02:09.05 | emte | ipkg is a great tool ... the frontend on the client needs some work |
02:09.47 | emte | shadows, what do you mean using? |
02:09.56 | shadows | like, inheriting it? |
02:10.23 | shadows | currently theres a number of packages that define the CVS tree seperately, but they are all from freedesktop anon cvs |
02:10.30 | shadows | so it should be fixed |
02:10.34 | shadows | i'm going to submit a patch |
02:10.39 | shadows | i wanted to know if that's okay |
02:11.31 | emte | i belive koen suggested changing it to ${FDO_CVS} |
02:11.35 | emte | or something like that |
02:11.42 | shadows | okay |
02:11.47 | emte | it seems fdo changes every couple months |
02:11.49 | shadows | where would FDO_CVS be defined? |
02:11.51 | shadows | no |
02:12.11 | shadows | it 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.16 | shadows | now i'm updating it |
02:12.33 | emte | its less 6months since fdo last changed their sources structure |
02:13.12 | emte | and i belive in local.conf with the others |
02:14.50 | emte | Feb 19 13:22:51 koen should be move to $FDO_CVS or something |
02:15.10 | shadows | oh |
02:15.24 | shadows | well these particular ones are grabbing from the xlibs branch of fdo anoncvs |
02:15.29 | shadows | so that actually looks okay |
02:15.42 | shadows | i'm changing it to an xlibs thing, easy enough to change later |
02:15.48 | emte | xcb apperently is the only change |
02:16.03 | emte | atleast as far as fdo's list has stated |
02:16.56 | emte | Feb 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.53 | emte | hmm |
02:53.01 | shadows | i'm going through all the files now and updating |
02:53.07 | emte | has BBDEBUG stopped working ? |
02:53.09 | shadows | it's an unbelievable quantity of files |
02:53.33 | emte | i think thats why $FDO_CVS was suggested |
02:53.57 | shadows | i split it up into three bbclass'es |
02:54.04 | shadows | it works more easily that way i think |
02:54.05 | emte | we had to do the same thing before for all the fdo projects a few months back |
03:00.20 | emte | hrm |
03:00.49 | shadows | only 3 more bb's to go |
03:00.52 | shadows | then i will make a diff |
03:07.36 | emte | hmm |
03:07.38 | emte | silly silly |
03:08.06 | shadows | http://bugs.treke.net/show_bug.cgi?id=706 |
03:12.55 | emte | hmm |
03:13.01 | emte | JustinP, you awake? |
03:13.10 | emte | or pb_ |
03:13.59 | emte | can one of you please push http://bugs.treke.net/show_bug.cgi?id=445 |
03:14.15 | emte | it shoudl have been done months ago |
03:24.18 | JustinP | emte: yeah, just wasn't online |
03:24.23 | JustinP | emte: what's up? |
03:24.39 | emte | actually ignore that request |
03:24.47 | emte | that change wont work |
03:25.42 | emte | strange ... why is it failing ... |
03:26.45 | JustinP | k |
03:27.34 | emte | NOTE: 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.59 | emte | why is it not parsing ... |
03:28.08 | JustinP | shadows: 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.48 | emte | okay it worked this time |
03:36.57 | emte | i must of had a bad char |
03:37.11 | emte | JustinP, 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.44 | emte | well i got h3600 sa-2.6 atleast configureing and partially building :) |
04:15.47 | emte | http://oe.pastebin.com/563879 |
04:16.14 | emte | heed 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.21 | emte | need* |
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.37 | emte | hrm... |
04:37.12 | *** join/#oe Geo_KM (n=keith@ppp47-111.lns2.syd6.internode.on.net) |
04:44.54 | JustinP | emte: I do? |
04:47.25 | emte | looks like i'll be adding somemore stuff to it soon |
04:50.29 | JustinP | well, if it's not working..... |
04:58.56 | emte | there |
04:59.07 | emte | cleaned 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.42 | shadows | JustinP: i was told that all builds need PR |
05:05.09 | emte | its debatable on your changes i think |
05:05.31 | shadows | well someone needed to do it |
05:05.34 | shadows | i did it. |
05:05.46 | emte | no, not the changes themselves |
05:05.58 | emte | if PR neede to be changed |
05:06.02 | emte | needed* |
05:06.31 | shadows | emte: that should be "do_configure ()" i think |
05:06.33 | shadows | notice the space |
05:06.39 | shadows | make sure it has the space AFAIK |
05:06.52 | emte | nah it wasnt that |
05:07.06 | emte | it was an invis char i inserted |
05:07.10 | shadows | ohhh okay |
05:07.54 | emte | teaches me to copy and paste out of my browser |
05:07.58 | emte | :P |
05:08.14 | emte | via gpm |
05:08.47 | emte | hurry up slocate .... |
05:08.56 | emte | i need smaller hdds |
05:09.08 | emte | then it wouldnt take so long |
05:10.50 | emte | AHA!!!! |
05:10.57 | emte | <PROTECTED> |
05:11.15 | emte | silly path change |
05:11.30 | emte | hrm ... |
05:11.49 | emte | on 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.25 | JustinP | shadows: 1) I was wrong, 2) no |
05:20.58 | JustinP | shadows: 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.35 | JustinP | shadows: 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.00 | JustinP | shadows: of course, to fix those SRC_URIs we could just use a simple sed script... |
05:22.11 | emte | on the otherside a PR bump is a marker for the URI change |
05:22.13 | poli | Is it some usual thing for gdb to "miss" addresses? |
05:22.27 | poli | I am getting an error from an address on the heap :S |
05:23.37 | JustinP | emte: marker? |
05:24.04 | emte | indicator when the URI change happened |
05:24.18 | emte | from a historical aspect |
05:25.57 | emte | like i said it could be debated either way |
05:26.06 | JustinP | not needed |
05:26.10 | JustinP | the revision # is enough |
05:26.33 | JustinP | if the code or build doesn't change there's no reason to bump PR |
05:26.37 | emte | PR is the revision number |
05:26.56 | JustinP | PR is used to tell the build system to build a new version and the installer to install a new version |
05:27.04 | JustinP | there is no reason to rebuild or upgrade with this change |
05:27.16 | JustinP | if you already have it built, using a new source will make no diff |
05:27.59 | JustinP | RP: looks like the interrupt isn't being called at all |
05:28.08 | emte | correct, but i belive if you already that the source version it will ignore the URI anyway |
05:28.18 | emte | s/that/have |
05:28.35 | JustinP | RP: and nothing is happening when I insert/remove the remote (although inserting and removing the module shows some output now) |
05:29.01 | JustinP | emte: ? |
05:29.20 | JustinP | emte: a new URI will cause a new fetch, yes |
05:29.38 | shadows | okay, noted |
05:29.43 | emte | really? never noticed it here ... |
05:29.44 | shadows | i'm going off what people told me to do before |
05:29.47 | JustinP | emte: it won't use the old tarball as the tarball name has the URI in it |
05:29.51 | emte | cept with cvs which is normal |
05:29.56 | shadows | and also my experience w/ Gentoo |
05:29.59 | JustinP | shadows: I must not have explained it very well before |
05:30.09 | shadows | hm |
05:30.14 | *** join/#oe decca (n=decca@203-59-28-79.perm.iinet.net.au) |
05:30.19 | shadows | feel free to patch it yourself ;) |
05:30.41 | JustinP | emte: do you know anything about kernel interrupts? |
05:30.46 | shadows | i feel it necessary to bump all the revisions and see what breaks |
05:30.55 | emte | JustinP, not enough to help you |
05:31.12 | JustinP | shadows: clean/rebuild |
05:31.15 | *** join/#oe Zero_Chaos (n=zero@pool-70-17-168-210.pitt.east.verizon.net) |
05:31.15 | shadows | 'cause right now, gpe/opie targets are going to be possible to build |
05:31.38 | shadows | s/are/are not/ |
05:32.41 | shadows | JustinP: the whole thing is going to need an overhaul soon enough |
05:33.06 | shadows | this is temporary "emergancy fix" until it gets changed |
05:36.07 | JustinP | ... |
05:36.11 | JustinP | what's the "real" fix? |
05:36.33 | JustinP | BTW, 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.45 | shadows | JustinP: the "real" fix is to mirror snapshots on an OE mirrorsite |
05:41.48 | shadows | and reference that |
05:45.55 | emte | shadows, thats not a real fix |
05:46.10 | emte | it has its own inherit issues |
05:46.31 | emte | mainly maintainance and staleness |
05:47.47 | JustinP | the real fix is to have *releases* which work |
05:48.11 | emte | lol |
05:49.09 | JustinP | either that or use the releases and then add patches which get it up to the point in CVS that we need |
05:56.53 | shadows | right |
05:57.05 | shadows | that'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.20 | emte | lolalright |
05:59.26 | emte | alright* |
05:59.34 | emte | lest see what my current mangling has done |
06:00.45 | emte | wanna see my patch so far? |
06:00.48 | emte | http://oe.pastebin.com/563937 |
06:01.02 | emte | 516 lines of fun |
06:01.44 | emte | hmm |
06:01.48 | emte | it didnt liek it |
06:03.13 | emte | hmm |
06:03.15 | emte | i wonder |
06:04.37 | JustinP | emte: jeez..... |
06:05.00 | emte | who me? |
06:05.02 | emte | :P |
06:05.18 | emte | the first 490 lines are changes in the defconfig |
06:06.11 | emte | basically the difference between the defconfig and runing it and saving it again via make menuconfig |
06:06.40 | JustinP | :-| |
06:07.02 | emte | i think the kernel-crew's defauly is a bit stale |
06:07.06 | emte | default* |
06:07.20 | emte | hence me fixing header paths |
06:10.40 | *** join/#oe [lala] (n=lala@p54B387DA.dip0.t-ipconnect.de) |
06:10.42 | emte | whoops 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.49 | emte | hmm |
06:25.22 | emte | grr |
06:26.12 | emte | http://www.handhelds.org/hypermail/kernel-discuss/13/1335.html |
07:01.34 | JustinP | grrrr |
07:01.38 | JustinP | interrupt! |
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.46 | emte | okay finally ... |
07:16.03 | emte | i 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.33 | emte | hey gremlin[it]work i found the threads on your kernel stuff :) |
07:31.55 | gremlin[it]work | yes :) |
07:32.13 | emte | i wish i had found em earlier |
07:32.39 | gremlin[it]work | i'll send a patch this evening for micro_key ... |
07:32.41 | gremlin[it]work | why ? |
07:33.02 | emte | spent a while patching paths before i found yours |
07:33.56 | gremlin[it]work | for h3600 ? |
07:34.00 | emte | yup |
07:35.41 | gremlin[it]work | it's about 6/9 months i start to take care oh h3600 for kernel 2.6 ;) |
07:36.25 | emte | yeah, its just not in the dev repo ... not sure which branch your on |
07:37.32 | gremlin[it]work | no i'm working just on kernel not on oe ... |
07:38.03 | emte | yeah, thats what i am thinking |
07:38.28 | *** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl) |
07:39.02 | gremlin[it]work | i have done some change on oe, i have a different h3600 machine to build with k26 ... |
07:46.53 | gremlin[it]work | probably 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.31 | alan|home | morning |
08:01.50 | *** join/#oe Ifaistos (n=stelios@dslcustomer169.vivodi.gr) |
08:02.08 | Ifaistos | Good morning all ! |
08:19.15 | hrw|work | mmornign |
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.42 | koen | good 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.17 | JustinP | woohoo! |
09:06.23 | JustinP | I'm getting interrupts |
09:08.00 | hrw|work | re |
09:09.43 | JustinP | and output |
09:09.49 | JustinP | no events, though |
09:09.57 | JustinP | at least I'm getting closer |
09:13.55 | CoreDump|home | morning |
09:16.22 | koen | hey CoreDump|home |
09:19.30 | CoreDump|home | yay ipkg upgrade fubar'ed my ROM yet again |
09:20.01 | koen | that makes no sense |
09:20.11 | koen | if it's Read Only, how can ipkg mess with it? |
09:20.53 | CoreDump|home | ~lart koen for pointing out the obvious |
09:21.04 | koen | :) |
09:21.11 | *** join/#oe [lala] (n=lala@ip-217-18-177-19.reverse.dsi.net) |
09:21.29 | gremlin[it]work | mhhh with a cold shower koen can completelly wakeup :) :) :) |
09:21.50 | gremlin[it]work | koe off-topic : what's your ppc board ? |
09:22.31 | koen | gremlin[it]work: the only powerpc board I have is my powerbook |
09:22.41 | koen | the rest is either arm, armeb or mips |
09:22.45 | gremlin[it]work | the loft board ? |
09:22.51 | koen | that's armeb |
09:23.11 | RP | morning all |
09:23.16 | koen | gremlin[it]work: http://www.giantshoulderinc.com/hardware.html |
09:23.18 | koen | hey RP |
09:23.38 | hrw|work | hi RP CoreDump|home |
09:24.23 | hrw|work | hi XorA |
09:24.31 | XorA | morning |
09:24.45 | koen | http://ewi546.ewi.utwente.nl/tinderbox/showbuilds.pl?tree=OpenEmbeddedBuilds |
09:24.52 | koen | we have a working tinderbox again |
09:24.59 | hrw|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.01 | koen | thanks to Zecke |
09:25.17 | koen | hey hrw|work & XorA |
09:25.46 | CoreDump|home | did anyone try abiword recently? It compiles and installs fine but crashes on start-up with an X error |
09:26.03 | CoreDump|home | hrw|work: =) |
09:26.27 | koen | CoreDump|home: http://handhelds.org/~bugzilla/show_bug.cgi?id=1520 |
09:26.51 | hrw|work | CoreDump|home: we had plans to ship it before fosdem |
09:27.03 | hrw|work | CoreDump|home: currently I feel that we will ship it in may or later... |
09:27.04 | CoreDump|home | koen: great thanks! |
09:27.17 | CoreDump|home | hrw|work: what's holding it up? |
09:27.51 | hrw|work | CoreDump|home: fscking keylauncher/matchbox problem in gpe |
09:28.10 | hrw|work | CoreDump|home: I vote for removing keylaunch at all from c*0 devices |
09:28.13 | CoreDump|home | then remove keylauncher and configure the keys via matchbox's config file |
09:28.17 | CoreDump|home | yep |
09:28.17 | koen | hrw|work: don't ship keylaunch |
09:28.50 | CoreDump|home | interestingly enough, GPE from .dev works fine heh |
09:29.15 | CoreDump|home | or maybe the newer xserver-common wasn't pushed into .dev only .oz |
09:30.03 | CoreDump|home | Also, personally, I would disable locale-base-* postinst completely |
09:30.49 | hrw|work | ~seen mickeyl |
09:30.51 | ibot | mickeyl 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.58 | JustinP | RP: oh, hey, morning |
09:33.09 | JustinP | RP: I'm getting interrupts :-) |
09:33.23 | JustinP | RP: it looks like it's all good, except for the ranges for the buttons..... |
09:33.55 | JustinP | RP: the values output by get_remocon_raw() are not unique for the different buttons... |
09:34.29 | RP | JustinP: That doesn't sound good :-/ |
09:34.31 | JustinP | RP: some of the buttons give different values, but most don't |
09:34.54 | RP | JustinP: Could your debugging code be interfering with the measurements somehow? |
09:35.01 | JustinP | RP: ATM, only vol up and vol down will work...:-| |
09:35.09 | RP | I guess we need to figure out exactly what its measuring... |
09:35.28 | JustinP | I doubt anything I added could have interfered....but I may be wrong |
09:35.42 | JustinP | MAX1111_REMCOM could be wrong, though |
09:35.53 | JustinP | you had it commented as possibly 0u, so I made it that |
09:36.25 | JustinP | not 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.36 | JustinP | http://oe.reversefold.com/sharpsl-rc.patch |
09:36.54 | RP | JustinP: Its the ADC channel on the MAX1111 I think the headphones are connected to |
09:37.04 | RP | See the Maxim MAX1111 datasheet |
09:37.24 | JustinP | ah.....well, I am getting different values for some of the buttons.... |
09:37.58 | koen | that's a start |
09:39.10 | JustinP | I'm just recompiling with altered constants to that I can hopefully see something come across the input device ^_^ |
09:39.35 | RP | I'd compare how its calling the max1111 functions with that in the sharp driver. |
09:39.59 | RP | I'm wondering if corgi_ssp might be broken somehow... |
09:40.35 | CIA-4 | 03koen 07org.oe.dev * r244cbc11... 10/conf/distro/angstrom-2006.9.conf: angstrom-2006.9: set distro version to test |
09:42.17 | JustinP | hmmmm |
09:42.26 | JustinP | 1u |
09:42.39 | JustinP | with a bunch of bit-shifting.... |
09:42.59 | JustinP | (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.46 | JustinP | (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.36 | RP | It means unsigned so its just a 1 character |
09:44.58 | JustinP | ah....wonder why I hadn't learned that previously... |
09:45.30 | JustinP | is the shitfing to have it work runtime with different devices or something....? |
09:46.50 | RP | Its just so you can see the bitbstatus of all the regsisters like PD0, PD!, SGL, etc |
09:47.46 | JustinP | could 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.03 | do13_ | morning all |
09:49.09 | JustinP | do13_: morning |
09:49.11 | RP | JustinP: The commands should be identical |
09:49.14 | RP | hi dirk |
09:49.44 | do13_ | Hi Richard, JustinP |
09:49.56 | JustinP | RP: so 1u == all that bit-shifting? |
09:50.22 | RP | JustinP: no, See +return corgi_ssp_max1111_get((channel << MAXCTRL_SEL_SH) | MAXCTRL_PD0 | MAXCTRL_PD1 |
09:50.22 | RP | +| MAXCTRL_SGL | MAXCTRL_UNI | MAXCTRL_STR); |
09:50.48 | JustinP | hmmm, ok |
09:51.01 | JustinP | oh |
09:51.02 | JustinP | pff |
09:51.08 | *** join/#oe cyphunk (n=cyphunk@tor/session/x-072ff0c8b4c62072) |
09:51.11 | RP | I suspect MAXCTRL_PD0 = (1u << MAXCTRL_PD0_SH) |
09:51.13 | JustinP | they were defined in the patch |
09:51.24 | hrw|work | hi Dirk |
09:51.35 | RP | Its also defined in the sharpsl_pm code |
09:51.50 | do13_ | hey Marcin |
09:51.51 | cyphunk | can the http://ipkgfind.nslu2-linux.org/ package search be trusted? Finding it hard to believe that libupnp is not in there yet |
09:52.10 | JustinP | oh.... |
09:52.13 | JustinP | ~lart me |
09:52.25 | koen | cyphunk: it can be trusted |
09:52.37 | CIA-4 | 03koen 07org.oe.dev * r0f3ce981... 10/conf/distro/angstrom.conf: |
09:52.37 | CIA-4 | angstrom.conf: |
09:52.37 | CIA-4 | * set default maintainer |
09:52.37 | CIA-4 | * put angstrom and version into image names |
09:52.38 | hrw|work | OE & OZ sucks badly when it comes to PR and informations... |
09:52.39 | koen | cyphunk: if it builds, ask NA|Zzz to include it when he wakes up |
09:53.14 | cyphunk | koen: it does build.... will do |
09:54.33 | koen | RP: is the git patch for lib/bb in svn yet? |
09:54.44 | koen | it seems we might need it for xlibs :( |
09:55.02 | JustinP | hmmm, no... |
09:55.42 | hrw|work | koen: iirc git fetcher is in trunk |
09:56.14 | JustinP | looks like 0u would give me the same thing as the Sharp code |
09:56.31 | koen | hrw|work: yes, but it's broken |
09:56.45 | koen | hrw|work: it needs http://www.rpsys.net/openzaurus/temp/bitbake_git-r0.patch |
10:00.00 | hrw|work | http://bugs.openembedded.org/show_bug.cgi?id=610 is useless probably (its gpe) |
10:00.05 | JustinP | ok, it's 2AM, I'm too tired to keep hacking |
10:00.39 | JustinP | RP: I would appreciate it if you could take a quick look and see if perhaps the corgi_ssp stuff is broken... |
10:00.39 | RP | koen: not yet. Its not going to happen until this evening. Too many other things to worry about today :-/ |
10:01.08 | JustinP | RP: it could also be the MAXCTRL constants defined in the patch perhaps... |
10:01.13 | koen | RP: no hurry, I have it applied locally :) |
10:01.16 | RP | JustinP: I suspect the bit bang code from the original sharp driver might ben needed |
10:01.24 | JustinP | lovely |
10:01.27 | *** part/#oe NA|Zzz (n=foo@220-253-9-123.VIC.netspace.net.au) |
10:01.45 | RP | It the bit bang code was for the max1111, that would be a problem |
10:02.36 | JustinP | well, it seems like I'm getting about 3 bits in my value...largest I've seen is 5 |
10:03.15 | JustinP | of course I'm completely speculating |
10:03.50 | JustinP | anyway, 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.10 | JustinP | at least it's coming along |
10:04.15 | JustinP | night |
10:04.36 | RP | JustinP: I'll try and have a look at the ssp code to refresh my memory. 'night |
10:05.07 | koen | 'night JustinP |
10:08.39 | XorA | ~seen mickeyl |
10:08.43 | ibot | mickeyl 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.15 | ldc | someone wanna submit a patch for perl_5.8.7.bb |
10:14.31 | XorA | ldc: what sort of patch? |
10:14.35 | ldc | For gentoo the following fixes are needed |
10:14.38 | ldc | <PROTECTED> |
10:14.38 | ldc | <PROTECTED> |
10:14.38 | ldc | <PROTECTED> |
10:17.24 | ldc | just cant understand why they use hardcoded path's in errno_pm.pl |
10:18.42 | XorA | ldc: 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.54 | ldc | xora: 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.16 | XorA | ldc: 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.16 | CoreDump|home | NOTE: multiple providers are available (glibc, glibc-intermediate); |
10:40.17 | CoreDump|home | NOTE: consider defining PREFERRED_PROVIDER_virtual/arm-linux-libc-for-gcc |
10:40.44 | CoreDump|home | Am I right to assume that if PREFERRED_PROVIDER is not set, OE uses the first one in the list? |
10:41.08 | koen | no idea, but in your case both options are fine |
10:41.21 | CoreDump|home | thanks =) |
10:41.23 | *** part/#oe subduerr (n=chopstix@cpe-66-8-255-241.hawaii.res.rr.com) |
10:41.25 | koen | although the glibc-i way is a bit longer |
10:42.48 | koen | with eabi we'd need glibc-i |
10:43.17 | CoreDump|home | One would thing something like that would be set in openzaurus*conf |
10:44.24 | CoreDump|home | ~lart minimo mirror |
10:44.35 | CIA-4 | 03koen 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.15 | CIA-4 | 03xora 07org.oe.dev * r1b17d5ea... 10/packages/offlineimap/offlineimap_4.0.11.bb: |
10:55.15 | CIA-4 | offlineimap_4.0.11.bb : add a new version with some proper dependecies |
10:55.15 | CIA-4 | on 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.18 | RP | koen: You had an error recently about a versioned dependency problem in gpe-session-scripts. Can you still reporduce it? |
11:11.29 | koen | sure |
11:11.38 | koen | bitbake gpe-sessionscripts with a recent bitbake |
11:11.54 | koen | gpe-session-scripts that is |
11:12.51 | RP | koen: ok, it was from a .bb in .dev? |
11:14.30 | hrw|work | ~curse tosa and poodle for being so unpopular |
11:14.31 | ibot | May you be reincarnated as a Windows XP administrator, tosa and poodle for being so unpopular ! |
11:14.59 | RP | koen: 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.28 | rob_w|mis | kergoth, 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.43 | hrw|work | someone 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.59 | katossi_uni | anyone 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.21 | CIA-4 | 03pH5 07org.oe.dev * r7130132b... 10/packages/linux/handhelds-pxa-2.6/ipaq-pxa270/defconfig: |
12:49.21 | CIA-4 | handhelds-pxa-2.6: upgrade hx4700 defconfig to 2.6.15-hh0 |
12:49.21 | CIA-4 | - reverts an accidental downgrade |
12:50.41 | CIA-4 | 03koen 07org.oe.dev * r3abff1bf... 10/packages/linux/ep93xx-kernel_2.6.15.bb: |
12:50.41 | CIA-4 | ep93xx kernel: update to derevo2 |
12:50.41 | CIA-4 | * serial should be working |
12:50.41 | CIA-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.19 | hrw|work | someone know which email Schurig use in OE bugtracker? |
12:53.54 | koen|away | Angstrom-gpe-image-test-20060220-ep93xx.rootfs.tar.bz2 |
12:53.55 | koen|away | yay |
12:53.59 | koen|away | gcc 4 works |
12:54.16 | CIA-4 | 03pH5 07org.oe.dev * r5940fb0f... 10/packages/avahi/avahi_0.6.7.bb: |
12:54.16 | CIA-4 | avahi: add 0.6.7 |
12:54.16 | CIA-4 | - See http://avahi.org/milestone/Avahi%200.6.7 and |
12:54.17 | CIA-4 | <PROTECTED> |
12:54.43 | gremlin[it]work | mhh just to know what board with ep93xx ??? |
12:55.37 | koen|away | gremlin[it]work: http://dominion.kabel.utwente.nl/koen/ep93xx/ http://glomationinc.com/products_9312-sx.html |
12:56.44 | gremlin[it]work | i 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.25 | hrw|work | bugs: 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.40 | CIA-4 | 03pH5 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.45 | CIA-4 | 03pH5 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.50 | chouimat | morning |
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.50 | greentux | hello |
13:57.57 | XorA | hey greentux |
13:58.32 | hrw|work | hi greentux |
14:01.38 | hrw|work | hi drw |
14:01.53 | greentux | hi hrw|work |
14:02.02 | greentux | hi XorA |
14:02.32 | zecke | hey |
14:03.25 | drw | morning |
14:04.32 | katossi_uni | my 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.31 | gremlin[it]work | koen|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.36 | koen | gremlin[it]work: I'll have to boot 2.6 first |
14:38.03 | gremlin[it]work | ouch !!! |
14:39.36 | koen | It's using some 'standard' which differs from what I want |
14:40.23 | gremlin[it]work | korean standard :) |
14:41.32 | gremlin[it]work | mainly 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.10 | koen | gremlin[it]work: we (actually [g2]) are going to work on gcc support for maverick |
14:43.26 | koen | gremlin[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.41 | Bernardo | hello guys |
14:52.01 | hrw|work | hi Jose |
14:52.10 | *** join/#oe AvengerMoJo (n=alex@207.44.242.115) |
15:02.40 | Bernardo | hrw|work: saw your message on the list, about oz354 |
15:03.04 | Bernardo | I'm sorry to say I haven't had much time to test stuff on my akita |
15:03.45 | Bernardo | but what I did seems to work without major bugs |
15:04.31 | Bernardo | only problem I found with a 354 image I built a week ago was with libxine playing qt movies, but that is minor |
15:07.20 | hrw|work | Bernardo: 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.57 | hrw|work | CoreDump|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.38 | cyphunk | very 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.57 | XorA | cyphunk: 2) will be done for you if your bb is right |
15:39.06 | cyphunk | XorA: thanks |
15:45.50 | cyphunk | under what conditions are custom do_* routines needed? |
15:46.23 | cyphunk | or will I need a do_install defined for all the files I want installed regardless of condition of the packages original makefile? |
15:46.40 | XorA | cyphunk: if make install works then you shouldnt need a custom do_install |
15:46.50 | cyphunk | righto |
15:46.51 | cyphunk | thanks |
15:47.59 | XorA | sometime 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.08 | XorA | autotools stuff is normally very simple |
15:48.30 | cyphunk | okay, 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.07 | gremlin[it]work | [g2] yes ... was one of the reason i don't bought it some months ago ... |
16:24.59 | gremlin[it]work | well 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.16 | cyphunk | I 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.17 | cyphunk | only the first time |
16:29.42 | cyphunk | I 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.47 | cyphunk | I missing something |
16:30.00 | gremlin[it]work | tmp/stamps |
16:30.23 | cyphunk | yeup, thanks |
16:30.27 | XorA | cyphunk: easy way is to use bitbake -c clean to remove workdir and stamps |
16:30.57 | cyphunk | XorA: 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.20 | XorA | cyphunk: yes, it just cleans workdir and tmp/stamps/packagename* |
16:31.29 | cyphunk | XorA: thanks |
16:32.01 | gremlin[it]work | yup thanks [g2] |
16:32.26 | *** join/#oe Timelord (n=TL@66.150.138.156) |
16:33.27 | cyphunk | XorA: I'm running it, is it supposed to "Handling BitBake files: | (0047/2800) [ 1 %]" before cleaning? |
16:33.48 | hrw|work | cu |
16:34.15 | XorA | cyphunk: you can use -b ../org.openembedded.dev/packages/spanner/spanner.bb to work with that single .bb file |
16:34.28 | cyphunk | okay, thanks |
16:34.35 | XorA | cyphunk: this is useful for developing bb's but it doesnt proces DEPENDS |
16:34.42 | XorA | cyphunk: so be careful |
16:34.53 | cyphunk | noted |
16:36.07 | *** join/#oe spit (n=spit@afe142.internetdsl.tpnet.pl) |
16:40.13 | gremlin[it]work | [g2] there is a site about linux on ep93xx ? |
16:44.34 | cyphunk | the 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.50 | cyphunk | can I just override do_compile() and chdir before running $OEMAKE ? |
16:45.06 | XorA | cyphunk: I beleive that is ok |
16:45.15 | cyphunk | XorA: okay |
16:45.17 | cyphunk | thanks |
16:45.24 | XorA | cyphunk: or maybe -C command to make |
16:45.53 | cyphunk | XorA: I guess that wouldn't hurt. not what the readme says (uses cd) but worth a try ;) |
16:46.28 | XorA | cyphunk: I lack finess when it comes to bb writing :-) |
16:47.26 | cyphunk | XorA: what's wrong with this IRC room... you should be chewing me out out not already knowing this shit ;) |
16:47.42 | XorA | cyphunk: we are the nice guys :-) |
16:48.54 | *** join/#oe W8TVI (n=me@166.165.152.194) |
16:50.32 | CosmicPenguin | But 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.18 | mndctrl | I'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.47 | XorA|gone | mndctrl: bitbake devshell is probably yhe easiest |
17:06.47 | mndctrl | devshell.. hmm, I'll look into it, tnx ;) |
17:10.19 | cyphunk | the 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.27 | cyphunk | how 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.42 | cyphunk | how 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.16 | reenoo | evening |
17:22.23 | poli | hello reenoo |
17:24.04 | reenoo | hi poli |
17:24.18 | reenoo | ~seen treke |
17:24.21 | ibot | treke <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.31 | reenoo | ~seen ggilbert |
17:24.33 | ibot | ggilbert <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.35 | johbrahms | hrw|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.24 | CIA-4 | 03koen 07org.oe.dev * r74ba86f4... 10/conf/machine/ep93xx.conf: ep93xx: use correct serial device |
17:48.37 | cyphunk | during do_install I get this error: "install: cannot create regular file `/usr/lib/libupnp.so.1.2.1': Permission denied" |
17:48.53 | cyphunk | err, I mean, do_stage phase, not do install |
17:49.03 | cyphunk | any ideas? |
17:49.04 | koen | looks like it doesn't obey DESTDIR |
17:49.10 | *** join/#oe Timelord0 (n=TL@66.150.138.156) |
17:49.12 | koen | it tries to install to your host system |
17:49.20 | cyphunk | yeah |
17:49.28 | cyphunk | there is no configure for the package |
17:49.32 | cyphunk | only the makefile |
17:49.37 | cyphunk | it takes $PREFIX from the env |
17:54.49 | cyphunk | any 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.07 | cyphunk | (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.13 | emte | cyphunk, 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.41 | pH5 | hi |
18:20.15 | emte | hey |
18:21.45 | zecke | RP: ping |
18:23.18 | zecke | pb_: hey |
18:23.39 | zecke | pb_: I have read that link (git and other SCMs) and I do not agree with most of keith is saying |
18:25.18 | pb__ | zecke: ah. |
18:25.33 | zecke | pb__: do you have that link again? |
18:25.44 | pb__ | let me look |
18:25.46 | zecke | pb__: I can't argue with the local support (I guess keith is living in portland) |
18:26.24 | pb__ | http://lists.freedesktop.org/archives/xorg/2006-February/013113.html |
18:26.25 | pb__ | that looks like it |
18:26.35 | pb__ | yeah, indeed he is |
18:26.48 | zecke | 1.) well kernel people are special :) |
18:26.53 | pb__ | I guess you can argue with him at fosdem |
18:27.17 | zecke | 2.) svn AFAIK will not modify existing files (well one text file saying which is 'HEAD') |
18:27.35 | zecke | 3.) well I can't argue that one - but I'm sure we have svn devels in berlin... |
18:28.00 | zecke | 4.) well cvs2svn converts everything :) |
18:28.30 | zecke | well and he does not take security, merging and daily usage into account |
18:30.09 | pb__ | right |
18:30.12 | pb__ | okay, that's interesting |
18:31.36 | zecke | I still get schocked when git asks me to do a merge |
18:35.50 | poli | zecke: why? |
18:36.08 | zecke | poli: because I need to google :} |
18:36.26 | poli | makes sense |
18:36.40 | zecke | poli: maybe this is a gnu ism... but I need to do the hard time merging using |
18:36.46 | zecke | git-ls-files --unmerged |
18:36.52 | zecke | and git-cat-file blob |
18:36.56 | zecke | and calling merge by hand |
18:38.28 | koen | zecke: keep in mind that git is only a distributed model of rcs |
18:38.48 | koen | zecke: and nobody uses rcs without cvs anymore |
18:38.48 | poli | hey... taken by how linus and stallman love each other... shouldn't be any gnuisms in git ;) |
18:39.11 | zecke | poli: git log is not working on FBSD and OSX |
18:39.36 | koen | zecke: I wonder why |
18:39.53 | koen | o wait, I know: only the linux kernel uses git |
18:40.00 | poli | lol |
18:40.01 | zecke | koen: GNU date gets called :) |
18:41.08 | shadows | you raise a very important point |
18:41.18 | shadows | the fdo stuff is not linux-only |
18:41.31 | poli | Linus and Stallman hate each other? |
18:41.37 | poli | Oh, that point... |
18:41.39 | shadows | yet the 'git' tool depends on GNU programs that are traditionally only on linux distro OSes |
18:42.17 | poli | WTF? livia:/tmp# md5sum /dev/hdb |
18:42.17 | poli | error processing /dev/hdb: failed in buffer_read(fd): mdfile: Input/output error |
18:42.18 | shadows | making it inappropriate to push onto developers of software that are used to developing on non-linux platforms |
18:42.31 | shadows | ERROR: Nothing provides runtime dependency xhost |
18:42.33 | shadows | err? |
18:43.03 | shadows | oh |
18:43.05 | shadows | i have an error |
18:43.11 | poli | Do I have a bad cd? |
18:43.59 | CIA-4 | 03koen 07org.oe.dev * r4812c9eb... 10/packages/linux/ep93xx-kernel_2.6.15.bb: |
18:43.59 | CIA-4 | ep93xx-kernel: update to derevo3 |
18:43.59 | CIA-4 | * ethernet is working |
18:43.59 | CIA-4 | * userspace reached with nfsroot |
18:46.52 | zecke | shadows: well, that is keith's issue :) |
18:47.38 | shadows | i think monotone is the best SCM i've seen |
18:47.45 | shadows | the speed issues are the problem |
18:48.10 | zecke | shadows: the lua integration makes merging a bit easier (as it can use meld...kdiff3) |
18:48.21 | zecke | shadows: but git is moving very fast |
18:54.52 | CosmicPenguin | and git is where the love is right now |
18:57.19 | koen | zecke: http://article.gmane.org/gmane.comp.version-control.monotone.devel/6110 |
18:59.17 | pb__ | 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.46 | zecke | pb__: later pal |
19:05.30 | koen | zecke: the monotone people seem genuinly interested in our needs |
19:05.37 | koen | maybe we should have a dialog |
19:06.23 | zecke | right, one should always have a dialogue |
19:06.36 | *** join/#oe gremlin[it] (n=gremlin@88-149-150-99.f4.ngi.it) |
19:07.13 | zecke | koen: it would be interesting to have a monotone 0.26 server available |
19:07.28 | zecke | to show people that it is way faster already (even if this new code is unoptimized) |
19:07.34 | koen | I could run on on dominion |
19:07.49 | koen | s/on on/one on/ |
19:07.52 | zecke | and we should create static packages so people can test easily (we need the root dir rename one) |
19:08.18 | zecke | I'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.29 | koen | nice |
19:08.29 | shadows | koen: i would help test a monotone 0.26 server |
19:08.38 | shadows | koen: i hear the speed improvements are worth it |
19:08.57 | koen | shadows: about 7-8 times faster pull on an OE tree |
19:09.11 | shadows | yeah. that plus decent hardware = less pain |
19:09.19 | koen | and maybe more with another delta storage method |
19:09.39 | zecke | shadows: on localhost a pull took only a couple of hours :} (Athlon XP 2600+) FBSD |
19:09.48 | zecke | shadows: which is already better than a couple of days |
19:10.14 | shadows | zecke: IIRC when working with Gentoo, a pull took about an hour and a half via cvs |
19:10.29 | shadows | which was the pinnacle of achievement |
19:10.29 | shadows | heh |
19:10.46 | shadows | i'll bet they're still using CVS because it is the fastest |
19:10.49 | zecke | it took 1:22m sys and user and I'm not sure if I need to add these values (output of time) |
19:11.02 | shadows | ah |
19:11.40 | zecke | ah okay |
19:11.53 | zecke | a pull took two hours (org.oe.dev) |
19:12.17 | koen | on what hardware? |
19:12.26 | zecke | Athlon XP 2600+ 1.5GB ram |
19:12.27 | koen | 0.25 takes ~8 hours on a dual opteron |
19:17.18 | zecke | okay a pull on localhost with 0.25 was killed after taking more than 12hours :) |
19:17.24 | zecke | (I killed it) |
19:17.35 | *** join/#oe zap (n=zap@217.170.93.196) |
19:19.25 | hrw|work | <PROTECTED> |
19:24.45 | hrw | hi |
19:25.12 | hrw | koen: that mail about monotone is about undo/logdir things? |
19:25.15 | koen | hey hrw |
19:25.19 | koen | hrw: yes |
19:25.28 | hrw | my work :) |
19:25.32 | koen | :) |
19:26.09 | hrw | i was discussing on #monotone when lacked monotone log dirname |
19:26.29 | hrw | I need more gettys on c7x0... |
19:26.47 | hrw | forgot to add some :( |
19:26.58 | zecke | I think more than one Gettys (Jim) won't fit on your c7x0 |
19:27.16 | koen | yeah, X is heavy |
19:27.29 | hrw | koen: X is fluuf |
19:27.55 | hrw | and over 20 years old so it must be rahter obsolete now.. |
19:28.09 | hrw | ~lart c760 keyboard a bit |
19:28.14 | zecke | Steve Jobs never liked it anyway |
19:28.33 | hrw | zecke: who liked Steve jobs... |
19:29.03 | zecke | hehe |
19:29.07 | koen | zecke: let me put on my black turtleneck and make some statements ;) |
19:29.43 | hrw | how goes #monotone talk? |
19:29.59 | koen | I'm writing an email right now :) |
19:30.25 | hrw | to oe? or monotone-dev? |
19:30.41 | hrw | if 2nd then cc: me pls |
19:34.01 | shadows | hrw: updates are now happening to X11 :) |
19:34.06 | shadows | XCB work is in place |
19:34.55 | hrw | shadows: nice - fdocvs thing? |
19:35.33 | shadows | the XCB is not included in my changes to fdocvs bb updates |
19:35.58 | shadows | in simple words, XCB is newer, lighter, and replaces Xlib |
19:36.12 | shadows | there is a compatibility work called XCB/Xlib |
19:36.36 | koen | xcb is also more async, right? |
19:36.45 | shadows | yes |
19:36.59 | shadows | it is intended for desktop use also |
19:37.03 | koen | xcb was very hot 3 or 4 years ago |
19:37.15 | shadows | the old xcb work seems to be unrelated now |
19:37.44 | hrw | Ill ignore it anyway |
19:37.53 | hrw | its .dev and its X |
19:38.12 | shadows | yeah |
19:38.41 | shadows | today 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.05 | hrw | koen: Ill try to remove keylaunch tomorrow from images, push some oz 3.5.4 things and TAG it |
19:39.20 | koen | nice |
19:39.31 | hrw | let mortal kombat^W^Wopenzaurus building begins |
19:39.33 | shadows | koen: do you want some bb's to lack the PR setting? |
19:40.17 | koen | shadows: it doesn't hurt |
19:40.35 | koen | but if it's set to 'r0' you can leave it in |
19:40.38 | shadows | my 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.02 | shadows | i know, i will split that change out more |
19:41.27 | shadows | should i still use the changes to add "PR" setting? i heard that -ALL- bb descriptions must have the PR setting |
19:41.44 | koen | bitbake sets it by default to r0 |
19:42.04 | shadows | okay |
19:42.05 | hrw | cu |
19:42.20 | koen | hrw|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.34 | koen | any suggestions/additions before I press send? |
19:43.10 | shadows | is there a feature that lets us only update the contents of the directory we're in? |
19:43.14 | shadows | i don't know monotone too well |
19:43.27 | shadows | i suppose that is not supported |
19:45.43 | koen | shadows: http://rafb.net/paste/results/QjSeRp41.html |
19:46.15 | *** join/#oe _frank (n=user@84.92.70.37) |
19:46.31 | shadows | yes there should be a sanity check for the merge tool |
19:46.36 | shadows | i like that suggestion |
19:47.11 | zecke | koen: I need to leave now :} |
19:48.21 | *** join/#oe stevenh (n=lews@65.167.23.2) |
19:48.31 | shadows | wow |
19:48.50 | shadows | JustinP was very clever in the work-around for gcc4 and the gtk-webcore builds |
19:49.00 | JustinP | shadows: was I now? ;-) |
19:49.09 | JustinP | shadows: surprised you didn't look at it when I committed it |
19:49.56 | JustinP | shadows: I even pasted it into the channel back then.... |
19:49.56 | shadows | nah, i just presumed your genius would save the day |
19:49.56 | shadows | and moved on to the rest of my fixes |
19:49.59 | JustinP | heh |
19:50.00 | JustinP | ok |
19:50.08 | shadows | that's really bloody clever, mate |
19:50.20 | koen | gcc4 fixes? |
19:50.29 | koen | it didn't build this morning |
19:50.32 | shadows | koen: gpe-image now builds with gcc4 as the cross-initial |
19:50.40 | koen | with bitbake trunk and OE head |
19:50.41 | JustinP | well....I took the general format from a webpage on sumulating ? : with python |
19:51.27 | shadows | koen: bugs related to gcc4 as cross-initial and OE targets should be directed to me |
19:51.31 | zecke | JustinP: only issue I have no PREFERRED_CROSS set |
19:51.45 | zecke | JustinP: I have a cset to 'fix' it pending so please do not do anything... |
19:51.54 | koen | shadows: http://rafb.net/paste/results/9E9BSU16.html |
19:52.19 | shadows | koen: blame that on JustinP ;) |
19:52.30 | shadows | koen: it works for me here |
19:52.51 | shadows | i think you need to have that variable set though |
19:53.03 | shadows | JustinP: does the build system automagically define that var? |
19:54.10 | zecke | cya later |
19:56.04 | *** join/#oe chewy (n=dieu@r2351064.cidc.net) |
19:56.56 | shadows | koen: what is your distro set to? |
19:57.26 | *** join/#oe W8TVI (n=me@166.165.159.187) |
19:57.34 | shadows | i'm guessing angstrom or maemo |
19:57.40 | koen | shadows: angstrom-2006.9 |
19:57.43 | shadows | yes |
19:57.52 | shadows | angstrom does not follow the behavior of the other distros |
19:58.03 | shadows | jnc@baker:~/opensource/openzaurus/org.openembedded.dev$ grep -rn PREFERRED_VERSION_gcc-cross * |
19:58.25 | shadows | follow that and you'll see what i mean; what is the correct thing to follow? |
20:00.40 | JustinP | shadows: must not, no |
20:01.14 | shadows | we must have a mechanism to say "this package will only build with x.y.z compiler" |
20:11.26 | pb_ | shadows: that would be DEPENDS, I suppose. |
20:11.46 | shadows | pb_: can you explain more? |
20:12.11 | shadows | or give an example of where that is done |
20:12.46 | pb_ | DEPENDS = "gcc-cross-3.4.4" |
20:17.48 | shadows | JustinP: what do you think |
20:18.39 | pb_ | or, alternatively, add an anonymous function that checks the compiler version and blows up if it isn't what you want. |
20:18.49 | shadows | oh |
20:19.08 | shadows | hey, what arguments do you give to 'diff' tool? |
20:19.17 | shadows | i've been using -bur but that blows up on Makefiles |
20:19.43 | pb_ | uprN |
20:20.48 | reenoo | hmm |
20:21.03 | reenoo | will PREFERRED_PROVIDER win over DEFAULT_PREFERENCE? |
20:21.10 | pb_ | yes |
20:21.31 | pb_ | DEFAULT_PREFERENCE is pretty weak, virtually anything will beat it |
20:21.41 | reenoo | ok, thanks |
20:22.00 | pb_ | I think the bitbake manual might have some words about that, actually. |
20:22.11 | pb_ | I certainly remember writng a description of how the resolution process works at one point. |
20:25.25 | shadows | hey all, what do you guys think about moving damageext and compositeext ... etc. into packages/xlibs? |
20:25.43 | shadows | that is according to where they get their files from SCM |
20:25.51 | shadows | i.e. xlibs fdo cvs |
20:26.19 | shadows | packages/gtk-webcore and packages/cairo currently do this |
20:26.41 | pb_ | sounds like a reasonable plan to me |
20:26.55 | shadows | does the directory name (damageext) factor into any of the variables? |
20:26.59 | pb_ | no |
20:27.05 | pb_ | it's just for convenience |
20:27.07 | shadows | okay so, that means just the name of the bb |
20:27.43 | shadows | in 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.52 | shadows | moving directories around like that would pooch the build |
20:28.03 | shadows | you're saying it's just for convenience, is that 100% sure? |
20:28.27 | pb_ | yeah. you could (approximately) do "mv */* opie-powerchord/" if you wanted, and everything would still work just fine. |
20:28.38 | shadows | excellent |
20:28.41 | pb_ | that actual command would probably fail because all the "files" directories would collide, but you get the general idea |
20:28.45 | shadows | i'll add that to my list of changesets to make |
20:28.55 | shadows | oh hmm |
20:28.57 | shadows | good point |
20:29.19 | pb_ | plus, obviously, having everything inside an opie-powerchord directory would be a dim plan in general. |
20:29.24 | CIA-4 | 03rw 07org.oe.dev * r0de420be... 10/packages/gtk-webcore/ (4 files): |
20:29.24 | CIA-4 | gtk-webcore: fix parse errors in 20060212 snapshots. |
20:29.24 | CIA-4 | <PROTECTED> |
20:29.25 | CIA-4 | <PROTECTED> |
20:30.07 | reenoo | pb_: yah, sorry. guess I should read a current version of it one of these days. |
20:30.19 | reenoo | shadows: that wasn't directed at you |
20:30.36 | shadows | reenoo: it only breaks if the variable is not set |
20:30.43 | shadows | i had no idea it was not set in Angstrom and maemo |
20:31.03 | shadows | i only checked familiar and openzaurus, the more popular targets. my mistake |
20:31.27 | reenoo | it doesn't really matter where it's set or not. it should never blow up. |
20:31.36 | shadows | true |
20:32.00 | shadows | the no-threadsafe-statics flag only exists in gcc4 though |
20:32.47 | shadows | i can't test for gcc3, since gcc3 doesn't exactly output sane code on my machine (amd64) |
20:40.19 | CIA-4 | 03koen 07org.oe.dev * ref0ce499... 10/packages/linux/ep93xx-kernel_2.6.15.bb: |
20:40.19 | CIA-4 | ep93xx-kernel: update to derevo4 |
20:40.19 | CIA-4 | * fixes reboot |
20:50.48 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
20:51.05 | shadows | ugh |
20:51.30 | shadows | insane quantity of files affected by the cvs URL |
20:52.31 | koen | shadows: that's why we usually put a magic var in bitbake.conf |
20:52.39 | pb_ | shadows: delete 'em all. let them eat tarballs. |
20:52.52 | shadows | i'm centralizing the vars |
20:52.58 | shadows | it's just a workaround for now |
20:53.13 | *** part/#oe law_ (n=_law_@213.173.86.202) |
20:53.17 | shadows | but it will allow us to easily grok for the files that need to be changed, when we have a proper fix |
20:53.20 | shadows | unlike now |
20:53.47 | shadows | btw i did a full gpe-image build with the previous changeset |
20:53.48 | *** join/#oe chouimat (n=dieu@kde/developer/chouinard) |
20:53.49 | shadows | it worked fine |
20:54.01 | shadows | so these changes i'm smoothing out should also inherently work |
20:54.31 | pb_ | ah, it's always nice when changes are inherently correct. |
20:54.34 | pb_ | zero defects! |
20:54.44 | shadows | heh |
20:55.05 | shadows | well 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.16 | shadows | one of them (xorg.bbclass) is -obviously- wrong |
20:55.33 | shadows | other than that, it built fine. |
20:55.45 | shadows | in fact, when the build broke, it was obvious where to fix the problem |
20:55.49 | shadows | =) |
21:03.40 | shadows | i guess this should instead all be in maybe some freedesktopcvs bbclass |
21:03.42 | shadows | i don't know |
21:04.01 | shadows | the changes i'm making now will nontheless make it easier to go to a better solution later |
21:04.05 | shadows | so i'm not worried about it now |
21:05.33 | CIA-4 | 03rw 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.42 | shadows | god dammit |
21:05.50 | shadows | here i am making all these changes |
21:06.16 | reenoo | well, here a sed script did all the work |
21:06.43 | shadows | did you do a search on 'pdx' or something? |
21:08.55 | shadows | http://bugs.treke.net/show_bug.cgi?id=706 |
21:09.34 | RP | shadows: I've back moving all the xlibs into one directory - I've been meaning to ask about doing that |
21:10.01 | shadows | RP: 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.19 | shadows | especially if they are from the same specific CVS branch |
21:10.33 | RP | shadows: It was once frowned upon but IMO the current directory is unmanagable |
21:10.47 | RP | <PROTECTED> |
21:10.50 | shadows | mmhm |
21:11.10 | shadows | i have only the gentoo and debian ways to compare with |
21:11.28 | shadows | debian is, you make several packages out of a single build description |
21:11.32 | shadows | i don't think that follows what we're doing at all |
21:11.54 | shadows | gentoo is, you have "sections" and a seperate directory for each package |
21:12.00 | shadows | we don't have sections |
21:12.07 | RP | Here its just convinience. I think it makes logical sense to combine them though |
21:12.09 | shadows | now 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.48 | RP | sections feel wrong in OE somwhow... |
21:12.54 | CIA-4 | 03eFfeM 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.04 | shadows | agreed |
21:14.57 | shadows | hrmmm multiple heads |
21:15.27 | shadows | is that usually happening while things are synchronizing accross servers? |
21:15.47 | reenoo | no, that happens when someone doesn't merge |
21:16.08 | shadows | oh |
21:16.11 | shadows | could you merge? |
21:17.18 | shadows | actually i think it's syncing now |
21:17.39 | shadows | it does appear that the tree is unmerged, when people make big commits that take a while to propogate |
21:17.51 | reenoo | no |
21:18.00 | shadows | no? |
21:18.05 | reenoo | no |
21:18.13 | *** join/#oe xep (i=misha@dsl027-176-045.sfo1.dsl.speakeasy.net) |
21:18.24 | koen | it happens when people make commits using the same ancestor |
21:18.30 | shadows | oh hmm |
21:18.44 | shadows | so after pushing a change, you'd have to pull again, then merge |
21:18.46 | shadows | and push again? |
21:18.49 | poli | shadows: it is actually something monotone considers "natural" |
21:18.55 | poli | But it is damn annoying! |
21:18.58 | shadows | heh |
21:19.26 | poli | Makes sense when you think your changes won't be spolied by an update... but... |
21:19.49 | CIA-4 | 03rw 07org.oe.dev * r517c224b... 10/packages/ (10 files in 5 dirs): more fd.o hosted packages: use FREEDESKTOP_CVS. |
21:21.22 | shadows | reenoo: you borked the useage of the xlibs bbclass, i think |
21:21.33 | shadows | i.e. made it depreciated |
21:21.45 | shadows | there was an xlibs bbclass before that defined the FDO CVS server |
21:21.58 | shadows | please have a look at that, and also comment on bug 706 |
21:22.44 | reenoo | nah, that's a different story |
21:23.13 | reenoo | although it should use FREEDESKTOP_CVS too, obviously |
21:24.46 | *** join/#oe greentux (n=m@195.227.105.180) |
21:29.17 | CIA-4 | 03rw 07org.oe.dev * r50ca4355... 10/classes/xlibs.bbclass: xlibs.bbclass: use FREEDESKTOP_CVS as well. Thanks to Eric Shattow for spotting. |
21:30.21 | shadows | stick a fork in my eye ;) |
21:30.33 | shadows | okay 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.11 | shadows | hey is anyone looking for a Sharp serial cable? |
21:35.25 | CIA-4 | 03florian 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.26 | shadows | there is one being sold (with SL-5500 attached ;) |
21:35.29 | CIA-4 | 03florian 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.38 | RP | shadows: Which country? |
21:35.41 | shadows | USA i think |
21:36.02 | RP | If it was the UK I might have been interested :) |
21:36.03 | shadows | i bought one from a china seller, and still have not received it |
21:36.11 | shadows | it's been a couple of weeks now |
21:36.16 | RP | :-/ |
21:36.17 | shadows | i think that i may have lost out on $50usd |
21:36.48 | pb_ | heh. it's probably just on the infamous slow boat from china. |
21:37.07 | shadows | that is true |
21:37.21 | CosmicPenguin | Thats a popular ship |
21:37.25 | shadows | when i did sales representation, for mfg companies, the "boat from china" was never on time |
21:37.51 | shadows | in 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.58 | shadows | where it would be sent back again |
21:38.01 | shadows | and take twice as long |
21:38.20 | shadows | eBay #5867800043 |
21:38.36 | shadows | also includes a camera attachment |
21:38.58 | shadows | RP: are you interested in the camera? |
21:39.13 | shadows | i may buy this and donate it to a dev if they want/need it for better support |
21:39.19 | RP | shadows: The original Sharp one? |
21:39.22 | shadows | yes |
21:40.04 | RP | shadows: Its a binary only driver and not particularly good quality now - I've not considered it worth any development effort... |
21:41.00 | shadows | ah |
21:43.26 | shadows | i'm looking around to find an addressbook PDA for my grandfather, replacing his old ZR series organizer |
21:43.32 | CIA-4 | 03florian 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.42 | shadows | the Palm units have no keyboard and are _very_ difficult to use for an elderly person |
21:44.08 | shadows | i think that the text on the zaurii looks too small |
21:44.15 | shadows | suggestions? |
21:44.22 | pb_ | I guess you can make the text on the Z as big as you want |
21:44.26 | shadows | hmm |
21:44.42 | shadows | that's true, the screens and keyboards are smaller than the ZR series though |
21:44.54 | shadows | i'm concerned about the text on the keys being way too small |
21:45.31 | pb_ | 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.45 | shadows | interesting |
21:51.51 | shadows | those look perfect in form |
21:54.45 | koen|tv | reenoo: 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.45 | reenoo | koen|tv: np, I just fixed the parse error. shadow did the gcc4 related part. |
21:59.51 | emte | shadows, if all you want is an address book buy a ROX |
22:00.01 | emte | or is it REX |
22:00.04 | shadows | yeah, just an addressbook |
22:00.05 | emte | one or the other |
22:00.10 | koen|tv | emte: REX |
22:00.43 | emte | cheap device originally made to clipon pagers etc |
22:00.45 | shadows | for 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.07 | shadows | his daughter gives him a Palm IIIc |
22:01.13 | shadows | i just about died laughing at that |
22:01.24 | shadows | what is he going to do with a freaking Palm pilot? |
22:01.59 | shadows | i barely do anything interesting with *mine*, and i've still got my vision and plenty of time to mess with configuration conflicts |
22:03.40 | emte | http://cgi.ebay.com/Almost-new-Xircom-REX-6000-Micro-PDA-PCMCIA-NR_W0QQitemZ5868290404QQcategoryZ38331QQrdZ1QQcmdZViewItem |
22:03.50 | emte | shadows, a basic REX device |
22:04.23 | emte | thats actually the nicest REX i've come across .... |
22:05.29 | shadows | it's kind of tiny |
22:05.37 | shadows | are those easy to read? |
22:05.42 | emte | yup thats what makes it nice |
22:05.49 | emte | fits in your pocket |
22:05.55 | shadows | oh |
22:06.11 | shadows | it does look nice, i'm thinking about something with a very large screen though, maybe wide format |
22:06.34 | emte | remember if you expect him to use it he has to be comfortable carying it arround |
22:06.44 | shadows | he's probably not going around town with it |
22:06.55 | shadows | if he is, it's going to live in a briefcase |
22:07.15 | shadows | one of our buddies has that sort of REX device, a little CF format card |
22:07.16 | emte | http://www.the-gadgeteer.com/review/rex_6000_review |
22:07.19 | shadows | it was great until it died |
22:08.17 | emte | review suggests finding a REX 5000 |
22:08.41 | emte | oh wait thats backwards i think .. |
22:10.06 | emte | http://www.epinions.com/content_11730521732 |
22:11.28 | emte | interesting ... |
22:11.32 | emte | <PROTECTED> |
22:12.23 | emte | hmm looks like the xzire |
22:12.29 | emte | zire* |
22:12.32 | emte | anyway off to physio |
22:12.46 | shadows | :) |
22:12.55 | shadows | the Psion 5 looks about right |
22:13.07 | shadows | it runs on AA batteries, has a decent keyboard |
22:13.28 | emte | buy him a sidekick :P |
22:36.40 | *** join/#oe zecke (n=ich@88.134.3.107) |
22:36.54 | zecke | re |
22:37.01 | RP | hi zecke |
22:37.50 | zecke | RP: I have a list of native packages RDEPENDING on non native versions |
22:38.11 | zecke | RP: I don't want to teach bitbake about native packages |
22:38.22 | zecke | RP: I think the proper fix is to change our meta data |
22:38.36 | RP | zecke: The meta data is wrong at the moment, yes |
22:39.00 | RP | zecke: The question is whether we set RDEPENDS="" or set it to native packages |
22:39.33 | zecke | RP: it is funny :) |
22:39.36 | RP | One way around the ASSUME_PROVIDED problem might be to agree that ASSUME_PROVIDED lists both depends and rdepends? |
22:39.42 | zecke | RP: quilt-native needs patch-native |
22:40.03 | zecke | RP: and patch native needs 'patch' (as it can't use quilt) available... |
22:40.19 | zecke | RP: and if you require it, it shouldn't be in a RDEPEND :) |
22:40.52 | RP | zecke: Do you require it at build time or runtime? |
22:41.09 | RP | zecke: We're always going to require some ASSUME_PROVIDED packages |
22:41.25 | zecke | RP: for quilt-native, we manually use 'patch' to patch quilt |
22:41.56 | zecke | RP: well, I think patch and gcc are cases where you simply 'require' them |
22:42.08 | RP | Adding patch-native to the default assume_provided is safe IMO |
22:42.45 | RP | It would be nice if the default ASSUME_PROVIDED line was the same as our list of prerequisite software |
22:43.27 | RP | zecke: We also have an explode_deps bug hanging around: See part of http://www.rpsys.net/openzaurus/temp/bitbake_git-r1.patch |
22:44.08 | zecke | RP: (not that I understand the explode bug) but we should fix the copy in OE as well |
22:44.40 | RP | zecke: Think of a version of the form (>= 2.3.4) - the space being critical |
22:44.47 | RP | zecke: What do you think about allowing both providers and runtime providers in ASSUME_PROVIDED? |
22:45.29 | RP | I agree we need to check the copy of that function in OE |
22:47.41 | zecke | RP: http://pastebin.ca/42390 |
22:49.09 | zecke | I'm a bit exhausted from gym, so give me some minutes to recover (before I stress my multitasking skill again) |
22:50.24 | RP | zecke: I think I see a flaw in your check as you might have only checked RDEPENDS, not RDEPENDS_${PN} |
22:50.37 | RP | zecke: but ignore me for a few minutes - I also have something I need to finish |
22:50.58 | zecke | RP: you can check the test soon :) |
22:53.30 | *** join/#oe Timelord (n=TL@4.78.4.43) |
22:55.44 | zecke | RP: http://svn.berlios.de/viewcvs/bitbake/trunk/bitbake_qa/modules/depends_checker/depends.py?rev=368&view=markup |
22:55.58 | zecke | RP: it has other bugs but it looks at RDEPENDS_${PN} :) |
22:56.29 | zecke | okay I will get some food now |
22:57.37 | RP | zecke: when you get back I have some comments ;-) |
22:57.40 | CoreDump|home | hi |
22:58.42 | CoreDump|home | hrw|gone: yes, I'm planning to do that. But I need to verify kernel 2.4 functionality first |
22:58.56 | RP | hi CoreDump|home |
22:59.29 | CoreDump|home | hello RP |
22:59.39 | zecke | I have not left |
23:00.30 | RP | zecke: 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.42 | RP | zecke: and you should be using explode_deps ;-) |
23:01.29 | zecke | (you have commit access) :) |
23:01.57 | RP | true. I have a job to finish, then I might use it :) |
23:02.21 | zecke | RP: for the explode_deps thing, could you send me a list of strings and how they should end up :) |
23:03.11 | RP | zecke: xxx (xx anything in brackets) should become simply xxx as far as bitbake is concerned |
23:03.54 | JustinP | shadows: I don't know what to think |
23:04.05 | RP | zecke: Note the version in OE does care about the version string. the one in bitbake does not |
23:04.28 | lamikr | I 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.30 | JustinP | RP: I don't suppose you've looked at the corgi_ssp stuff? I'm going to try to look at it now.... |
23:04.34 | lamikr | module_autoload_omapts = "omapts" |
23:05.34 | pb_ | that sounds about right. did you rebuild the kernel afterwards? |
23:06.03 | zecke | my slive of bread should be toasted by now |
23:06.08 | zecke | slice even |
23:06.14 | pb_ | thanks for the bulletin |
23:07.31 | lamikr | pb_: 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.48 | pb_ | lamikr: what do you have in /etc/modules.d/? |
23:08.11 | zecke | pb_: you are welcome :) |
23:08.14 | zecke | pb_: do you want some as well? |
23:08.20 | RP | JustinP: 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.22 | pb_ | zecke: no thanks, I just ate dinner |
23:08.26 | *** join/#oe ruied (n=ruied@213.22.166.23) |
23:08.34 | zecke | you are lucky :) |
23:09.05 | zecke | RP: I have one question: if I remove the BUILD_ALL_DEPS from native.bbclass and build the opie-image |
23:09.13 | lamikr | pb_: At least after boot I do not have /etc/modules.d at all. |
23:09.24 | zecke | the RDEPENDS get build anyway |
23:09.35 | CIA-4 | 03rw 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.57 | pb_ | lamikr: oh, sorry, it's /etc/modutils/ |
23:10.00 | RP | zecke: Yes. I'm not sure that's a problem? |
23:10.05 | CosmicPenguin | argh |
23:10.12 | JustinP | RP: well that's good news of a kind. I'll look into the command thing... |
23:10.40 | RP | JustinP: 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.54 | RP | JustinP: but that would be attributed to other things... |
23:10.54 | zecke | RP: this is due the opie-image.bb BUILD_ALL_DEPS right? |
23:11.00 | RP | s/would/could |
23:11.27 | RP | zecke: anything that inherits the image .bbclass, yes |
23:11.33 | CosmicPenguin | note to self - read the bb before building it |
23:11.53 | pb_ | CosmicPenguin: ah, you accidentally bitbaked r00tk1t.bb? |
23:12.12 | CosmicPenguin | heh |
23:12.40 | pb_ | I hate it when that happens |
23:12.58 | JustinP | RP: hmmm... |
23:13.06 | *** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com) |
23:13.10 | lamikr | pb_: 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.28 | RP | JustinP: It shouldn't be too difficult to establish my functions are equivalent to sharp's. |
23:13.47 | RP | JustinP: You could also try copying sharp's functions into the driver to compare their readings |
23:13.51 | pb_ | lamikr: is kernel-module-omapts actually in your image? If so, what files does it contain? |
23:14.12 | RP | JustinP: see arch/arm/mach-pxa/pxa_ssp.c for them |
23:14.35 | JustinP | RP: ah, thanks (was just grepping) |
23:14.46 | zecke | RP: do we want native packages to have RDEPENDS at all? |
23:16.10 | RP | zecke: I still say yes and that we should have ASSUME_PROVIDED handling the ones we don't want built |
23:16.52 | lamikr | pb_: 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.55 | zecke | this means a patch-native.bb may not use 'patch'? |
23:17.24 | pb_ | lamikr: ah, do you mean that you have defeated the kernel module splitting? |
23:17.28 | RP | zecke: Obviously there are some things that must be provided by the host system |
23:17.29 | pb_ | if so, yeah, that will also break autoloading |
23:18.17 | RP | zecke: 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.39 | lamikr | pb_: Not sure... I have just selected in my .config that omapts is build as a module. |
23:18.59 | pb_ | lamikr: well, which package contains the .ko file you mentioned? |
23:19.04 | zecke | RP: this might be a good start and documenting the REQUIREMENTS |
23:19.39 | zecke | damn it |
23:19.48 | RP | zecke: I did see it having that advantage :) |
23:20.18 | zecke | when was gtk-webcore touched? |
23:21.18 | lamikr | pb_: 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.29 | JustinP | RP: well, the MAX1111 defines seem to be equivalent |
23:22.21 | pb_ | lamikr: what files are inside that package? |
23:24.34 | zecke | reenoo|afk: *sorry* |
23:25.26 | CIA-4 | 03freyther 07org.oe.dev * raa1b3639... 10/packages/gtk-webcore/ (4 files): |
23:25.26 | CIA-4 | gtk-webcore: |
23:25.26 | CIA-4 | <PROTECTED> |
23:25.26 | CIA-4 | <PROTECTED> |
23:25.30 | CIA-4 | 03freyther 07org.oe.dev * r623eed7c... 10/classes/tinderclient.bbclass: |
23:25.30 | CIA-4 | classes/tinderclient.bbclass: |
23:25.30 | CIA-4 | <PROTECTED> |
23:25.31 | CIA-4 | <PROTECTED> |
23:25.33 | CIA-4 | <PROTECTED> |
23:26.51 | zecke | RP: should we add a method |
23:27.04 | zecke | that automatically add '-native' to RDEPENDS |
23:27.28 | lamikr | pb_: 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.40 | pb_ | okay |
23:27.41 | zecke | RDEPENDS = "$@{oe.create_depends(['m4', 'autoconf'],d)} |
23:27.56 | pb_ | lamikr: so, you need to figure out why that /etc/modules/omapts is not showing up in your installed system |
23:28.40 | RP | zecke: Given most bb files include their non-native counterparts, it would be even better if we could just translate that... |
23:28.52 | RP | translate their RDEPENDS |
23:29.07 | zecke | this requires to do the 'include' before the inherit |
23:29.45 | zecke | reenoo|afk: I will disapprove my merge (due the meld error...) once viewmtn is available |
23:30.01 | CosmicPenguin | ~lart udev |
23:30.18 | RP | zecke: I know, I'm not sure its technically possible :-/ |
23:30.50 | pb_ | zecke: I don't think the order should matter much. You can use a function. |
23:31.47 | zecke | pb_: like RDEPENDS := "${@fix_up(d)}"? |
23:32.31 | pb_ | no, that would indeed have the ordering problem. more like: |
23:32.34 | zecke | RP: one good thing about 'patch' is. I have BSD patch and a GNU patch works way better with quilt |
23:33.30 | pb_ | python __anonymous () { bb.data.setVar("RDEPENDS", bb.zecke.mungeRdepends(), d) } |
23:33.31 | pb_ | kind of thing |
23:34.06 | zecke | pb_: do you know when __anonymous is evaluated? |
23:34.11 | pb_ | yes |
23:34.22 | lamikr | pb_: 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.56 | zecke | pb_: so enligthen me please :) |
23:35.03 | pb_ | zecke: at the end of parsing |
23:35.34 | zecke | pb_: I had hoped for that. Now let us find out if it is still true |
23:36.52 | zecke | (I think it is) |
23:38.11 | pb_ | 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.28 | pb_ | presumably you are only running one kernel at any one time |
23:39.41 | pb_ | anyway, this doesn't sound like an autoloading problem so much as the driver just plain being not installed. |
23:39.50 | lamikr | pb_: 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.57 | pb_ | okay. sounds like you need to add the modules you want to ${HANDHELD_MODULES} or whatever your equivalent to that is. |
23:41.02 | lamikr | Is this correct in my machine-conf: |
23:41.03 | lamikr | BOOTSTRAP_EXTRA_RDEPENDS += "${@linux_module_packages('${H6300_MODULES}', d)} |
23:41.16 | pb_ | looks about right, yeah |
23:41.24 | pb_ | what's ${H6300_MODULES}? |
23:41.43 | lamikr | # |
23:41.44 | lamikr | H6300_MODULES = "omapts i2c-omap pca9535 omap-keypad nfs \ |
23:41.45 | pb_ | zecke: let's hope it still is |
23:41.46 | lamikr | # |
23:41.48 | lamikr | bluetooth rfcomm bnep l2cap hci_uart h6300_bt" |
23:42.29 | pb_ | that looks ok |
23:42.29 | pb_ | what are the dependencies on the generated task-bootstrap.ipk? |
23:42.35 | lamikr | they are in: http://pastebin.ca/42407 |
23:43.16 | pb_ | eh, that looks like your MACHINE.conf or something |
23:43.28 | pb_ | are you sure that is the right pastebin url? |
23:45.16 | lamikr | pb_: I thought you meant that. How can I check the task-bootstrap.ipk dependencies? |
23:45.32 | pb_ | use "dpkg-deb -I", or "ipkg status" |
23:47.46 | lamikr | pb_: 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.30 | lamikr | pb_: But I dound my taksbootstap.control file from rootfs that contains dependencies: it is in http://pastebin.ca/42425 |
23:57.08 | lamikr | and it seems that for some reason it does not list kernel modules as a dependencies... |
23:58.30 | zecke | RP: the automatic replacing won't work |
23:58.50 | zecke | e.g. foo-common is okay in RDEPENDS |
23:59.26 | RP | zecke: ok, we'll jsut have to go though and set the RDEPENDS correctly then I guess |
23:59.33 | zecke | java-virtual-machine should be virtual/java-machine-native |
23:59.57 | RP | zecke: Did you have any thoughts on whether allowing ASSUME_PROVIDED to cover both types of depends was good/bad? |