**** BEGIN LOGGING AT Sat May 28 23:59:56 2005
May 29 01:32:14 <koen> good morning all
May 29 01:38:26 <ljp> hi
May 29 01:39:00 <koen> hey ljp 
May 29 01:44:37 <ljp> when's that hildon rom out? ;)
May 29 01:45:14 <koen> :)
May 29 01:55:21 <CIA-4> 03mickeyl 07 * r1.3440 10openembedded/ (3 files in 2 dirs): move unzip(-native) to 552, add DESCRIPTION
May 29 03:18:36 <uv1> Good morning all!
May 29 03:23:45 <uv1> Anyone here ?
May 29 03:27:40 <uv1> Ping !
May 29 03:28:06 <uv1> What is the actual version of bitbake ? Where to get it ?
May 29 03:29:37 <koen> hello,yes, pong, dunno, svn
May 29 03:31:08 <uv1> Just did it and have 1.1 now.
May 29 03:31:53 <koen> koen@dominion:/data/build/oe/build$ bitbake --version
May 29 03:31:53 <koen> BitBake Build Tool Core version 1.3.0, bitbake version 1.2.9
May 29 03:33:20 <uv1> My actual prob is, that bitbake -D e2fsprogs gets stuck in parsing the first file in cache. It does not return an error, just is stuck.
May 29 03:33:35 <uv1> I have the same version of bitbak, than you.
May 29 03:33:41 <uv1> Any idea ?
May 29 03:33:45 <koen> try removing the cache
May 29 03:34:43 <uv1> Sometimes, the obvious things work ;-)
May 29 03:35:15 <uv1> koen: Do you know, why mkfs.ext2 (3) is not in the standard package any more ?
May 29 03:36:38 <koen> no idea
May 29 03:36:54 <uv1> building e2fstools ...
May 29 03:37:43 * luke-jr_ ponders if he should add it to oz-ljr =p
May 29 03:42:53 <luke-jr_> uv1: you mean e2fsprogs?
May 29 03:43:16 <uv1> luke-jr_: s/e2fstools/e2fsprogs/
May 29 03:43:32 <uv1> Problem : checking for LC_MESSAGES... yes
May 29 03:43:32 <uv1> checking for bison... bison
May 29 03:43:32 <uv1> checking version of bison...
May 29 03:43:41 <uv1> Here it stucks.
May 29 03:44:03 <CoreDump|afk> uv1: reomve the "yacc" symlink from staging and rebuild bison-native
May 29 03:45:30 <uv1> Thanks CoreDump|afk : building bison-native now ...
May 29 03:48:46 <pb_> morning
May 29 03:49:59 <uv1> Another one. Wanted to rebuild the full OZ stuff this morning incl. 2.6.12 kernel (c7x0). Build stopped at gnu-config. Path did not apply.
May 29 03:50:39 <koen> bk pull and/or move the cvsdate forward
May 29 03:52:08 <uv1> koen: Did a bk pull before. Howto move the cvsdate forward ?
May 29 03:52:36 <uv1> e2fsprogs does not contain mkfs.ext2 :-( Where is it gone ?
May 29 03:53:56 <koen> uv1: gnu-config needs a recent gnuconfig, so check your local.conf and ${DISTRO}.conf for any stray CVSDATE=<reallyold>
May 29 03:54:06 * luke-jr_ adds dosfstools & e2fsprogs to oz-ljr ;)
May 29 03:55:50 <mickeyl> *yawn*
May 29 03:55:51 <mickeyl> morning folks
May 29 03:56:01 <CoreDump|afk> morning mickeyl 
May 29 03:56:11 <pb_> hi mickey
May 29 03:56:13 <uv1> morning mickeyl
May 29 03:57:35 <BigAl> morning
May 29 04:00:03 <uv1> mickeyl: I am searching for mkfs.ext2. Expected that to be in e2fsprogs, but is NOT. Any idea ?
May 29 04:00:48 <uv1> CoreDump|home: BTW. Rebuild of bison-native helped. Thanks.
May 29 04:00:50 <mickeyl> uv1: just look closer at the output of your packages. you probably overlooked the package e2fsprogs-mke2fs 
May 29 04:01:52 <CoreDump|home> uv1: np
May 29 04:02:50 <CoreDump|home> mickeyl: I've used build an image w/ 3.5.4 config and CVDATE from yesterday. It still has the sdcontrol / busybox issue
May 29 04:03:02 <CoreDump|home> s/used/just/
May 29 04:03:50 <mickeyl> that's sad
May 29 04:03:57 <mickeyl> we didn't touch busybox since ages
May 29 04:03:57 <uv1> CoreDump|home: Is that the reason why an SD card is not mounted during boot ?
May 29 04:04:07 <CoreDump|home> uv1: yeah
May 29 04:04:26 <CoreDump|home> uv1: running /etc/sdcontrol insert manually works though
May 29 04:05:04 <CoreDump|home> mickeyl: I know. Will try to install an older (working) version of BB and test again
May 29 04:07:12 <uv1> What is the best kernel for real working with c7x0. 2.6.11 or 2.6.12 ?
May 29 04:07:31 <zecke> hey
May 29 04:07:34 <zecke> mickeyl: ping
May 29 04:07:35 <luke-jr_> 2.4
May 29 04:07:59 <luke-jr_> 2.6 kernels have a few issues still
May 29 04:08:39 <uv1> luke-jr_: But with 2.4, the device does not wake up from sleep, if I remember right ...
May 29 04:08:39 <luke-jr_> mainly, occasional suspend issues, nonfunctional microphone, and 'reboot' acting as 'halt'
May 29 04:08:51 <luke-jr_> uv1: 2.4 always worked for me...
May 29 04:09:00 <uv1> linuxwhor1: CL860 ?
May 29 04:09:06 <luke-jr_> 2.4's only problem is mic conflicts w/ audio out
May 29 04:09:08 <luke-jr_> 760
May 29 04:09:13 <luke-jr_> should be same hardware
May 29 04:10:00 <uv1> luke-jr_: opie ?
May 29 04:11:50 <luke-jr_> GPE
May 29 04:13:33 <CoreDump|home> I've just seen the same reboot = halt problem,on a collie w/ 2.4 :)
May 29 04:15:10 <uv1> CoreDump|home: Did not find /etc/sdcontrol on my device. Which package ?
May 29 04:16:01 <zecke> mickeyl: pb_ : I would like to add a possibility to 'deroute' logs in bitbake
May 29 04:16:02 <CoreDump|home> uv1: ah, sdcontrol is only used for 2.4 kernels
May 29 04:16:44 <pb_> zecke: what would that do?  I'm not sure I understand what derouting is.
May 29 04:17:19 <uv1> Since 2.6 kernel I get 3 messages "Bad erase block ..." while booting. Do you think it is a device problem ?
May 29 04:18:03 <zecke> pb_: For my tinder-client I would like to more easily get access to the logs 
May 29 04:18:26 <zecke> pb_: so I want bb.note to write to a file and same applies to run.do_*
May 29 04:18:50 <pb_> ah, right
May 29 04:18:50 <pb_> sounds fine
May 29 04:19:05 <zecke> doesn't have the highest priority yet (though)
May 29 04:21:13 <CoreDump|home> mickeyl: hah
May 29 04:21:30 <CoreDump|home> replacing /bin/busybox _does_ solve the problem
May 29 04:22:36 <CoreDump|home> yep, works perfectly now
May 29 04:26:59 <CoreDump|home> hmm maybe "4 weeks   	1.24  	add CELF patch for more ash builtins" has some sideeffects
May 29 04:29:02 <uv1> CoreDump|home: Which busybox did you use ?
May 29 04:29:21 <CoreDump|home> the one from yesterday heh, the most up-to-date in OE anyways
May 29 04:29:54 <CoreDump|home> ahh you mean the old one? It' maybe a week older than the 3.5.3 release
May 29 04:30:13 <CoreDump|home> I'm trying to narrow down the problem
May 29 04:31:28 <CoreDump|home> rebuilding the old version in the current environment now
May 29 04:36:53 <CoreDump|home> filesize is identical, booting
May 29 04:37:43 <CoreDump|home> ok, works. So it's not some library-gone-nuts but indeed busybox itself
May 29 04:45:30 <CoreDump|home> ok, I've found the problem. It is indeed the CELF patch. Removing it results in a working BB
May 29 04:48:50 <CoreDump|home> should I file a bug report?
May 29 04:49:22 <koen> if its breaks, yes
May 29 04:49:39 <CoreDump|home> ok, will do
May 29 04:58:37 <CoreDump|home> http://bugs.openembedded.org/show_bug.cgi?id=47
May 29 05:08:04 <CIA-4> 03CoreDump 07 * r1.3441 10openembedded/packages/portmap/files/portmap.init: portmap: Unb0rk initscript: /etc/init.d/portmap stop works now
May 29 05:18:48 <Yog> pb_: Hi. I'm still trying to get the bootldr working on my CL4. cmartin said, that you might probably know something about the problem, that the bootloader thinks it has 32MB flash, when there are only 16MB. are there any patches ?
May 29 05:20:21 <zecke> Yog: nope
May 29 05:20:31 <zecke> Yog: then change the source to only utilize 16mb
May 29 05:20:34 <zecke> (one define)
May 29 05:21:09 <CoreDump|home> bleh, reboot & halt are broken, too
May 29 05:24:14 <Yog> zecke: oke. As far as I understand to get a new bootloader image I would basically have to build a working linux image with a special kernel which does not protect the flash, and then this images launches the bootloader-elf image which then itself installs the new bootloader.
May 29 05:24:57 <zecke> Yog: that is cmartins approach
May 29 05:25:18 <Yog> so give me an easier one ;-)
May 29 05:25:44 <[g2]> Yog what are you reflashing ?
May 29 05:25:47 <zecke> solder jtag, put the bootldr into flash
May 29 05:26:04 <zecke> Yog: load a bootldr to ram, flash the real bootldr into flash..
May 29 05:26:28 <zecke> Yog: but do whatever you want ;)
May 29 05:28:33 <[g2]> During the last couple days in #openjtag we've been discussing JTAG'ing a bootloader directly onto the icache of the IXP4xx
May 29 05:28:49 <Yog> zecke: the second approach would be the easiest one, however I'm not sure how to do that (that's also true for cmartins approach), as I cannot flash anything because the current bootloader stops with the 16MB flash erasing error. 
May 29 05:29:24 <Yog> zecke: are there any commands to disable erasing the flash before flashing ?
May 29 05:29:34 <pb_> Yog: you don't need the bootloader-elf step; you can just flash the bootloader directly from within the kernel, if your kernel allows writing to that region of flash.
May 29 05:30:00 <[g2]> a motto from nslu2-linux is "Friends don't let friends flash bootloaders without JTAG" :)
May 29 05:31:30 <pb_> [g2]: here in #oe we positively encourage it
May 29 05:31:55 <Yog> pb_: the problem for me is how to flash anything right now with this erasing flash error. I just try everything to avoid building the jtag ;-)
May 29 05:32:22 <pb_> [g2]: regarding your ixp4xx icache thing, yeah, that should work.  There is some code in handhelds.org cvs to do that for the pxa255.
May 29 05:33:38 <pb_> in fact, on one pxa255 machine that I worked with last year, the CPU was booted that way as standard in production units.
May 29 05:34:36 <pb_> Yog: what state is your pad in at the moment, exactly?  Do you have a valid rootfs image in flash?
May 29 05:34:49 <pb_> can you boot the kernel, or does the bootldr problem prevent that?
May 29 05:35:29 <Yog> pb_: no, no kernel, no image, no roofs. but the bootloader loads correctly. ;-)
May 29 05:35:36 <pb_> heh
May 29 05:35:51 <pb_> okay.  well, I guess you could load a kernel into RAM (over serial) and then boot it with root on NFS or something
May 29 05:36:11 <pb_> or, load a combined kernel+initrd image with enough marbles to get you to a shell prompt
May 29 05:36:56 <Yog> so the bootloader can boot an image from ram, that's at least a possible way.
May 29 05:37:13 <pb_> right
May 29 05:37:56 <pb_> I don't remember the exact syntax, but I think it's something like load ram 0xc0008000, then boot addr 0xc0008000 0x100000
May 29 05:38:37 <pb_> actually, probably not 0xc0008000.   might need to google to find the right address.
May 29 05:39:09 <pb_> or just experiment: something like 0xc0400000 is most likely
May 29 05:40:04 <pb_> then, once you have a working kernel, you can use flash_erase and dd to install your new bootloader
May 29 05:40:22 <Yog> does the bootloader only accept jffs2 images ?
May 29 05:41:33 <pb_> for ram loading, you mean?
May 29 05:41:43 <Yog> yes
May 29 05:42:07 <pb_> no, it wants a bootable zImage (or zImage+initrd)
May 29 05:42:24 <pb_> it doesn't know how to unpick a jffs2 in ram.
May 29 05:45:20 <zecke> pb_: assuming EVENTLOG from base.bbclass originates from you, did you test lately?
May 29 05:45:42 <Yog> pb_: oke, thanks. That will take me some time building such an image ... 
May 29 05:46:07 <pb_> Yog: or, in theory, you can build a ram-bootable bootldr, load that directly into ram, and then you should be in business.
May 29 05:46:17 <pb_> I'm not sure how well that works in practice though
May 29 05:46:35 <pb_> zecke: I don't think it does originate from me.  You should probably turn your attentions towards kergoth.
May 29 05:47:13 <Yog> pb_: so that the bootloader loads the bootloader, correct ?
May 29 05:47:20 <pb_> right
May 29 05:47:51 <pb_> if you check in your bootldr directory, it's probably built a ram-bootldr.bin image.
May 29 05:49:33 <Yog> pb_: no, it hasn't. probably I should first build an bootloader from the current cvs.
May 29 05:49:49 <pb_> be careful, the current cvs doesn't have any simpad support
May 29 05:50:26 <pb_> flashing one of those images would almost certainly make your situation much worse than it is now
May 29 05:50:26 <pb_> heh
May 29 05:51:31 <Yog> mmh, so bootldr-simpad01 from July 2004 is the recent version for the simpad, or are there better ones ?!
May 29 05:52:13 <zecke> no better ones
May 29 05:53:21 * Yog thinks that he is the last one on this planet with a cl4 running linux on it
May 29 05:58:20 <pb_> probably
May 29 05:58:37 <pb_> I wouldn't be too surprised if you are the last one on this planet with a cl4, full stop
May 29 05:58:37 <pb_> heh
May 29 06:02:01 <Yog> anyone here who wants to to swap an cl4 simpad with a sl4 ??? ;-))))
May 29 06:17:47 <[g2]> pb_, THX for info about the pxa255 ! :)
May 29 06:20:15 <Spyro> whats a cl4 ?
May 29 06:20:25 <koen> Spyro: simpad
May 29 06:20:31 <Spyro> oh.
May 29 06:20:34 <koen> 800x600 tablet thingy
May 29 06:20:35 <Spyro> I kinda wanted one of those
May 29 06:20:44 <koen> see opensimpad.org
May 29 06:24:51 <Spyro> koen: other than the RAM / flash are the CL and SL versions the same? or a redesign ?
May 29 06:25:04 <koen> I think they are the same
May 29 06:25:15 <koen> but I've only seen one sipad in my life :)
May 29 06:31:53 <Yog> spyro: imho the design is a little bit different, but hardware is the same (except flash/ram) 
May 29 06:32:56 <Spyro> Theres a couple on ebay right now... I might see if I can get one :-)
May 29 06:33:58 <Spyro> I wonder if handhelds.org would be able to design, manufacture, and market a PDA...
May 29 06:38:31 <CoreDump|home> the design phase would be hard enough, but manufacture and market? You'd need professionals for that
May 29 06:38:54 <CoreDump|home> and a ton of cash of course :)
May 29 06:39:20 <Spyro> isnt that sort of thing what freenode is all about ?
May 29 06:39:41 <Spyro> funding open stuff, etc.
May 29 06:39:52 <CoreDump|home> dunno
May 29 06:40:56 <CoreDump|home> lets assume some would design the PDA from scratch in his free time (that alone would take ages), you'd need a _ton_ of cash to manufacture it and then you still haven't run a single advertisment
May 29 06:41:21 <Spyro> I know people who can do the hardware design
May 29 06:42:42 <CoreDump|home> nice :) However, still still leaves the question of funding. One would need to research the initial cost to produce a prototype
May 29 06:42:54 <Spyro> indeed
May 29 06:43:00 <BigAl> Prototyping is always expensive, too.
May 29 06:43:08 <CoreDump|home> prototype as in "finished design", not a dev board :D
May 29 06:43:21 <Spyro> indeed
May 29 06:43:26 <Spyro> actually
May 29 06:43:31 <Spyro> the biggest cost is getting a case
May 29 06:43:58 <CoreDump|home> um the PCB / mainbaord won't be cheap either I'd think
May 29 06:44:45 <BigAl> It's not cheap to get multilayer boards fabbed in small quantities, if nothing else.
May 29 06:45:44 <CoreDump|home> plus, in order to sell it, It must not suck ;) Users see a product w/ different eyes than devs. That would need to be examined, too
May 29 06:46:10 <Spyro> yes
May 29 06:47:17 <mickeyl> zecke: hi. when will you release bb 1.3 ? i have some more refactorings necessary for the shell which I'd like to commit afterwards.
May 29 06:47:18 <CoreDump|home> ljp can possibly comment on the costs. TT is bound to work closely w/ manufacturers
May 29 06:48:02 <Spyro> I think initially a wince-form-factor device w/ VGA, USBhost *2 CF, SD*2, and a non-stupid docking conector (USB OTG port for sync port ?)
May 29 06:48:26 <CoreDump|home> Spyro: 2CF and 2SD would make this thing pretty large
May 29 06:48:35 <Spyro> not 2*CF
May 29 06:48:37 <Spyro> 2*SD
May 29 06:48:41 <zecke> mickeyl: that depends on kergoth
May 29 06:48:48 <zecke> mickeyl: I can tag/copy
May 29 06:48:51 <Spyro> theres plenty of room for 2*SD
May 29 06:49:24 <CoreDump|home> Spyro: the controller in my collie for SD is pretty large, larger than a CF card
May 29 06:49:31 <mickeyl> zecke: ok, then please tag/copy :)
May 29 06:49:38 <Spyro> the controller in my e330 is ~6mm square
May 29 06:49:51 <CoreDump|home> Spyro: nice :) that's that then heh
May 29 06:50:19 <Spyro> we'd want WiFi and BT as options (plug in mezzanine boards)
May 29 06:50:26 <[g2]> Spyro, do you really know the hw guys ?
May 29 06:50:28 <Spyro> those are really tiny these days anyway
May 29 06:50:44 <CoreDump|home> so we have VGA, CF 2*SD and a non-sucking docking port. WiFi and BT should be onboard IMO. 
May 29 06:50:51 <zecke> mickeyl: did my moving of update_data change anything?
May 29 06:50:52 <Spyro> g2: I know some guys yes - I recon they could pull this off.
May 29 06:51:12 <Spyro> CoreDump|home: WiFi at least should be replaceable
May 29 06:51:19 <Spyro> or start with 802.11g
May 29 06:51:19 <[g2]> why would they be interested in doing it ?
May 29 06:51:32 <Spyro> g2: money ;-)
May 29 06:51:53 <[g2]> money short-term or money-long term ?
May 29 06:51:57 <zecke> CoreDump|home: if you start with a PXA27x you've CF/SD/SDIO on chip
May 29 06:51:59 <CoreDump|home> Spyro: agreed. But if you go the 54MBit route, the device might need an uber-sucking binary-only driver
May 29 06:52:05 <[g2]> and how much risk are they willing to take ?
May 29 06:52:10 <Spyro> I dont think it matters to them - they're a small concern
May 29 06:52:24 <Spyro> CoreDump|home: hence make it pluggable
May 29 06:52:32 <Spyro> CoreDump|home: I suppose BT neednt be pluggable
May 29 06:52:33 <mickeyl> zecke: it looks to me as both cases work now, so it seems to have fixed the issues
May 29 06:52:38 <CoreDump|home> indeed
May 29 06:52:49 <Spyro> BT and WiFi could both sit on an internal USB2 bus so no need for big connectors
May 29 06:53:04 <[g2]> Spyro, I'd think the PDA market just got squashed with the intro of the '770
May 29 06:53:16 <CoreDump|home> maybe sell "free" 11Mbit devices and 54Mbit as an option. Since it's "pluggable" that won't be a problem
May 29 06:53:16 <Spyro> g2: we'll see.
May 29 06:53:30 <Spyro> CoreDump|home: indeed
May 29 06:53:52 <Spyro> g2: what the 770 proves is that theres room to drive the cost down
May 29 06:54:19 <CoreDump|home> oh, and it would need at least 128MB of RAM, and a healthy portion of flash
May 29 06:54:22 <[g2]> Spyro, I'm trying to build hw right now
May 29 06:54:23 <Spyro> CoreDump|home: in fact, why not a GSM module... pick any two, GSM, WiFi, BT ;-)
May 29 06:54:36 <[g2]> not for the PDA market but other markets
May 29 06:54:47 <Spyro> CoreDump|home: 256MB RAM - these days its dirt cheap and why not max out the PXAs address space
May 29 06:55:34 <Spyro> oh, and no internal FLASH per-se. use a semi-internal SD card or something
May 29 06:55:39 <CoreDump|home> gee, that sound like a killer machine
May 29 06:55:54 <Spyro> that way we could sell a 'DIY' kit with no add ons or OS
May 29 06:56:03 <CoreDump|home> Spyro: good idea, maybe 512MB SD or so plugged behind the battery or some such
May 29 06:56:09 <Spyro> and theres no need for people to worry about their internal flash wearing out
May 29 06:56:17 <Spyro> CoreDump|home: exactly
May 29 06:56:35 <Spyro> 'want debian on it and still have all your expansion slots? no problem sir'
May 29 06:57:23 <CoreDump|home> :D
May 29 06:57:50 <CoreDump|home> sounds like quite a nice machine :)
May 29 06:57:59 <Spyro> oh and I want SD slots that work at the full 12MB/sec or so that SD is capable of
May 29 06:58:10 <Spyro> none of that poxy 800k/sec crap
May 29 06:58:22 <[g2]> "Mike Dell --  Ideas area easy, executioni is hard" :)
May 29 06:58:29 <Spyro> in fact...
May 29 06:58:31 <[g2]> "Mike Dell --  Ideas area easy, execution is hard" :)
May 29 06:58:43 <Spyro> on the card reader side... why not shove that on a USB bus internally too?
May 29 06:59:21 <Spyro> my fastest SD read/writer is a USB2 8-in-1
May 29 06:59:23 <CoreDump|home> Spyro: hmm dunno. whatever the connection method, you'll still need a controller PCB
May 29 06:59:47 <Spyro> CoreDump|home: yeah but theres probably a dozen or so 4 port USB2 chipsets out there
May 29 07:00:09 <CoreDump|home> hmmm 4-port :) that would be overkill though heh
May 29 07:00:15 <Spyro> and the USB drivers for most stuff 'just work' on ARM even
May 29 07:00:22 <Spyro> CoreDump|home: not really.
May 29 07:00:26 <[g2]> Spyro, which USB2.0 chipset are you going to use ?  The NSLU2 with the NEC USB2.0 across the PCI bus can't run full USB 2.0 rates
May 29 07:00:36 <CoreDump|home> Spyro: even with "SD" ? Are there OSS SD drivers?
May 29 07:00:40 <Spyro> 4 ports = 1 card reader + WiFi + BT + sync port
May 29 07:00:52 <Spyro> CoreDump|home: I wrote one :)
May 29 07:01:00 <Spyro> CoreDump|home: the 2.6 SD code is basically mine
May 29 07:01:02 <CoreDump|home> Spyro: ah
May 29 07:01:04 <CoreDump|home> :D
May 29 07:01:34 <[g2]> Spyro, congrats... Did you see that wrt54g with the 512SD hack ?
May 29 07:01:42 <zecke> Spyro: do you plan to insert write-protect in the mmc block device?
May 29 07:01:43 <Spyro> g2: even if it doesnt hit 480Mbits/port, 10Mbits is enough for the WiFi / BT / sync
May 29 07:02:02 <Spyro> g2: yeah, thats a cute hack :)
May 29 07:02:21 <Yog> pb_: I haven't advanced that far yet ... perhaps you can give me another hint: you said I should do load ram 0xc400000. I guess that's the start of the mapped sdram, correct ?
May 29 07:02:23 <Spyro> zecke: I have never seen a MMC card with WP
May 29 07:02:58 <Spyro> Im just kinda tired of linux on handhelds being second fiddle to wince
May 29 07:03:22 <Spyro> it'll never change until we bring out a linux device that is BETTER (the zaurus aint it)
May 29 07:03:57 <koen> the 770 is a step in the good direction
May 29 07:04:14 <Spyro> the 770 has nothing new hardware wise, however
May 29 07:04:37 <koen> quite old in fact
May 29 07:04:43 <Spyro> and it still fails to perform as well as a handheld could
May 29 07:05:05 <Spyro> SD slots at 800K/s is pitiful
May 29 07:05:08 <koen> I'm curious how well the dsp performs
May 29 07:06:35 <CoreDump|home> Spyro: ok, so now we have the perfect PDA. But by the sound of it, it might be quite expensive for the enduser (700-1000?)
May 29 07:07:50 <Spyro> CoreDump|home: I dont see why
May 29 07:08:03 <Spyro> CoreDump|home: USB controller will be cheap enough
May 29 07:08:23 <Spyro> USB card readers are under 5ukp including PCB and casing so the ICs for that have to be cheap too
May 29 07:08:36 <Spyro> BT / Wifi modules will be under 30ukp each
May 29 07:08:38 <CoreDump|home> just search for a current PDA w/ these features
May 29 07:08:44 <CoreDump|home> or similar
May 29 07:08:49 <Spyro> CoreDump|home: they dont exsit m8 :)
May 29 07:09:05 <CoreDump|home> hehe true
May 29 07:09:05 <Spyro> but thats because they are all weird and proprietary (to some extent)
May 29 07:09:25 <Spyro> think about it - all the stuff in this one is 'off the shelf' 
May 29 07:09:51 <Spyro> we need a tiny rom to get our initial SD driver running, so that we can load the OS off the 'boot SD card'
May 29 07:10:06 <Spyro> the sync port is a standard USB OTG port
May 29 07:10:10 <CoreDump|home> indeed
May 29 07:10:18 <Spyro> PCMCIA/CF is built into the CPU
May 29 07:10:19 <CoreDump|home> what's it called? mini-usb?
May 29 07:10:28 <Spyro> something like that
May 29 07:11:48 <reenoo_> afternoon
May 29 07:11:56 <Spyro> so all we really need is a small PCB with PXA27x (smallest ROM size will suffice for the 1st stage loader) USB 2.0 host controller with 4-6 ports (at least one OTG port), 256MB RAM, video controller, PCMCIA buffers
May 29 07:12:06 <Spyro> thats it
May 29 07:12:09 <CoreDump|home> yep
May 29 07:12:23 <Spyro> the rest is all sockets and power management
May 29 07:12:41 <CoreDump|home> ok, we need a codename for this beast :)
May 29 07:12:53 <Spyro> 'DMSDDD' ?
May 29 07:13:00 <CoreDump|home> hmm?
May 29 07:13:07 <Spyro> (Die MS Die Die Die) ;-)
May 29 07:13:11 <CoreDump|home> lol
May 29 07:13:34 <Spyro> seriously though, thats one simple PCB and one potentially killer device
May 29 07:13:37 <CoreDump|home> ThePDAThatDoesn'tSuck TPTDS
May 29 07:13:47 <Spyro> the PCB is simple on the scale of a Gumstix
May 29 07:13:53 <Spyro> TITS
May 29 07:14:00 <Spyro> (well it'll attract the lads)
May 29 07:14:05 <CoreDump|home> lol
May 29 07:14:17 <Spyro> IWO
May 29 07:14:21 <Spyro> (I want One)
May 29 07:14:27 <CoreDump|home> hmm openpda.org and freepda.org are taken, to bad :)
May 29 07:15:23 <CoreDump|home> IWO hmmm, has a ring to it
May 29 07:15:44 <Spyro> it does doesnt it? ;-)
May 29 07:15:51 <CoreDump|home> :)
May 29 07:16:26 * CoreDump|home is tempted to set up a page w/ its specs ;)
May 29 07:16:30 <RP|tablet> "morning" all
May 29 07:17:40 <reenoo_> hey RP|tablet 
May 29 07:17:56 <luother> how can i tell bitbake to use gcc 2.9.5? I tried with "ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95"" but he still compiles gcc 3.4 for cross compiling
May 29 07:18:04 <CoreDump|home> hi RP 
May 29 07:18:11 <reenoo_> RP|tablet: you don't happen to be in the "Bertha" room do you?
May 29 07:18:40 <RP|tablet> reenoo_: Which room is that?
May 29 07:18:41 <koen> hey RP|tablet 
May 29 07:18:41 <pb_> Yog: no, it needs to be the start of the mapped sdram plus a bit.
May 29 07:18:49 <RP|tablet> Next to the Nokia one?
May 29 07:18:49 <koen> RP|tablet: with the mono talk
May 29 07:19:12 <RP|tablet> I'm not in a talk atm
May 29 07:20:02 <koen> RP|tablet: cunningly hiding your kde installation?
May 29 07:20:45 <RP|tablet> koen:  Playing with my new toy ;-)
May 29 07:20:53 <koen> RP|tablet: you bastard!
May 29 07:21:05 <reenoo_> RP|tablet: n770?
May 29 07:21:13 <RP|tablet> yes :)))
May 29 07:21:17 <zecke> nice
May 29 07:21:42 <RP|tablet> I keep breaking it :)
May 29 07:21:46 <koen> RP|tablet: http://dominion.kabel.utwente.nl/koen/blog/pyblosxom.cgi/Handhelds/maemo-z.html
May 29 07:22:08 <Yog> pb_: because google didn't turn up anything useful. I've uploaded a kernel arm zImage to 0xc0400000, but then boot ram 0xc0400000 complains about the wrong kernel magic (which is indeed wrong). the reported wrong kernel magic doesn't even change when I try load ram 0x0300000 ?! So I guess the ram start is not correct ?!
May 29 07:23:24 <RP|tablet> koen:  Very neat :)
May 29 07:23:48 <RP|tablet> koen: I'll mention that to our matchbox guru :)
May 29 07:24:20 <RP|tablet> koen: At this rate, we'll have it building out of oe before it hits the shelves :))
May 29 07:24:20 <koen> have you met the KC gang already?
May 29 07:24:28 <RP|tablet> KC?
May 29 07:24:39 <koen> kernelconcepts
May 29 07:25:23 <RP|tablet> not yet, no
May 29 07:26:25 <RP|tablet> I'm sure I'll bump into them sooner or later
May 29 07:27:07 <koen> they might be wearing white tshirts with a blue hand
May 29 07:27:35 <RP|tablet> brb
May 29 07:27:52 <reenoo_> koen: doesn't look like maemo is going to work too well on 320x240 devices :/
May 29 07:28:57 <koen> reenoo_: the real good part is in the gnome-vfs + libosso layers anyway 
May 29 07:31:26 <CIA-4> 03CoreDump 07 * r1.3442 10openembedded/ (2 files in 2 dirs): Update altboot to its latest version: combined bootSD and bootCF into one file as most functions were duplicated anyways
May 29 07:31:57 <koen> reenoo_: their bluetooth integration seems very nice
May 29 07:32:45 <reenoo_> koen: is that just a gnome-vfs plugin or have they patches gnome-vfs extensively as well?
May 29 07:32:53 <reenoo_> s/patches/patched/
May 29 07:33:07 <koen> they have gnome-vfs-extras and a patches gnome-vfs-dbus
May 29 07:33:18 <koen> patched even
May 29 07:33:58 <koen> florian is looking into de-maemoing it so we can use the mainline gnome-vfs 
May 29 07:36:34 <reenoo_> ah, right
May 29 07:39:06 <koen> as far as there is a 'mainline' version of it
May 29 07:52:35 <Hertog> hmmpf, I believe I might have found something wrt the serial stuff
May 29 07:55:44 <Hertog> serial_core.c:  printk("%s%d", drv->dev_name, port->line + drv->name_base); this is the patched line, original hasn't got the + drv->name_base
May 29 07:56:00 <pb_> Yog: I think you need "boot addr", not "boot ram"
May 29 07:56:20 <Hertog> would it be unreasonable to assume that somewhere else in the code the + drv->name_base is forgotten?
May 29 07:57:05 <Yog> pb_: sorry, that was just a typo, I meant "boot addr"
May 29 07:57:36 <pb_> ah, heh
May 29 07:57:41 <pb_> what did you use as the second argument?
May 29 07:58:08 <pb_> it needs to be equal to or greater than the size of the kernel you loaded.
May 29 07:58:55 <pb_> hi reenoo_ 
May 29 07:59:15 <mickeyl> Hertog: did you figure out how the cardmgr picks up the serial port number ?
May 29 07:59:33 <Yog> pb_: 0x100000 and 0x050000. kernel zImage has 900Kb, about 1,1MB uncompressed.
May 29 07:59:41 <reenoo_> hey pb_ 
May 29 08:00:21 <Hertog> mickeyl: yes, via DS_GET_DEVICE_INFO
May 29 08:00:23 <pb_> Yog: okay.  0x050000 would be too small, that's only about 300KB.  But 0x100000 should be ok
May 29 08:00:33 <mickeyl> Hertog: ah wait - let me read your mail
May 29 08:00:45 <Hertog> mickeyl: long and winding :)
May 29 08:02:11 <mickeyl> ok, DS_GET_DEVICE_INFO
May 29 08:02:23 <mickeyl> let me see where and howthis is implemented
May 29 08:02:30 <Hertog> ds.c
May 29 08:03:28 <Hertog> mickeyl: but I am looking at the pxa_serial_hack patch, and found that, in serial_core.c we add drv->name_base to port->line
May 29 08:04:02 <Hertog> mickeyl: and I cannot find that anywhere else. could it be that this adding should be done somewhere else too.. it is exactly the offset we need (3)
May 29 08:05:03 <mickeyl> hmm
May 29 08:05:03 <mickeyl> ah 
May 29 08:05:05 <mickeyl> it's not in ds.c
May 29 08:05:14 <mickeyl> not in recent kernels
May 29 08:05:17 <mickeyl> pcmcia_ioctl.c
May 29 08:05:46 <Yog> pb_: http://pastebin.com/291691 ... even completely wrong parameters result in exactly the same error ?!
May 29 08:07:44 <mickeyl> Hertog: in pcmcia_ioctl:387 the name gets copied out of dev_name
May 29 08:08:29 <Hertog> mickeyl: yeah, figured that out, I think :)
May 29 08:08:52 <mickeyl> so dev_name seems still to contain ttyS0 ?
May 29 08:09:06 <Hertog> yes
May 29 08:10:10 <Hertog> upon inserting the card it displays ttyS3, but that is because we add '3' to it, my guess is that the cosmetic part is taken care of (the printk) but the value that gets passed on is still the orriginal
May 29 08:15:28 <Hertog> mickeyl: for example, line 2170 if serial_core.c:
May 29 08:15:30 <Hertog> tty_register_device(drv->tty_driver, port->line, port->dev);
May 29 08:16:10 <Hertog> port->line is not 'changed' here as it is in the uart_report_port function
May 29 08:23:47 <Zero_Chaos> the wiki still has directions to obtain oe metadata from bitkeeper, is that correct?
May 29 08:24:29 <reenoo_> yes
May 29 08:24:32 <pb_> Yog: that does seem a bit odd
May 29 08:24:49 <Zero_Chaos> thank you.
May 29 08:25:27 <Zero_Chaos> is it better to svn bitbake, or is the ebuild updated frequently?
May 29 08:26:01 <Yog> pb_: just trying to flash an image with no_erase=1 ... perhaps that's what I need ?
May 29 08:26:08 <pb_> zero_chaos: right now, you almost certainly need the svn version
May 29 08:26:29 <pb_> I don't know how recent the ebuild is, but anything older than about three days will not work
May 29 08:26:46 <Zero_Chaos> pb_: I figured at much, thank you.
May 29 08:27:01 <pb_> Yog: dunno.  what's no_erase=1_
May 29 08:27:11 <pb_> s/_/?/
May 29 08:27:30 <Spyro> Hi guys.
May 29 08:27:31 <zecke> oh bitbake-1.2.1 should still 'work' - with the known bugs (ASSUME_PROVIDED)
May 29 08:27:37 <Yog> pb_: I dunno ... just found it in params. but it sounds good ;-)
May 29 08:27:43 <Spyro> Been speaking to my hardware contacts
May 29 08:28:32 <pb_> zecke: I don't think 1.2.1 can parse the current version of busybox.bb
May 29 08:29:36 <CoreDump|home> it can't
May 29 08:29:49 <CoreDump|home> Spyro: what do they say?
May 29 08:30:32 <pb_> Yog: heh
May 29 08:31:05 <mickeyl> Hertog: ok, that looks like the patch needs to get a larger part :)
May 29 08:31:15 <mickeyl> s/larger/additional/
May 29 08:31:45 <Spyro> They say that SPI would be a better choice for WiFi and BT modules, and that a GSM module would be relatively easy to add. USB OTG and VGA out are easy enough,and accelerated VGA LCD isnt a problem either
May 29 08:31:56 <Hertog> mickeyl: Do all the port->line elements be offsetted agains name->base?
May 29 08:31:59 <Spyro> also I2S for audio consumes less power
May 29 08:32:05 <Hertog> name_base that is
May 29 08:32:19 <zecke> Spyro: so PXA27x
May 29 08:32:34 <Spyro> zecke: there may be better lower power choices than 27x
May 29 08:32:46 <Spyro> particularly some omaps with built in DSPs.
May 29 08:34:38 <mickeyl> Hertog: can you see where the port name is constructed? is the minor number taken into account at all ?
May 29 08:35:57 <mickeyl> urghs
May 29 08:35:59 <mickeyl> hmm
May 29 08:37:30 <mickeyl> i don't know the semantics of port->line, whether it is a logical or a physical line
May 29 08:37:43 <mickeyl> we might as well try to add name_base to all of 'em and see what breaks :)
May 29 08:40:17 <koen> Spyro: too bad the compiler for dsp code is $5400
May 29 08:40:46 <Spyro> koen: we'll cross that bridge when we come to it...
May 29 08:41:56 <koen> I'm sure there are/will be free alternatives
May 29 08:44:16 * CoreDump|home wonders if it possible to boot an initrd.bin file straight off the sd card
May 29 08:44:53 <Spyro> CoreDump|home: I've done it...
May 29 08:45:06 <CoreDump|home> Spyro: interesting
May 29 08:45:20 <CoreDump|home> how did you get to the content of the initrd.bin?
May 29 08:45:31 <Spyro> CoreDump|home: loop mounted it
May 29 08:45:36 <CoreDump|home> heh
May 29 08:45:39 <Hertog> mickeyl: in serial_cs.c, function setup_serial, minornumbers are taken into account
May 29 08:45:47 <CoreDump|home> doesn't work on my Z for some reason
May 29 08:45:54 <CoreDump|home> jffs2 magic
May 29 08:48:04 <Spyro> CoreDump|home: I've fired off an email about this to the hardware guys. We'll see what they say.
May 29 08:48:10 <CoreDump|home> :)
May 29 08:49:28 <CoreDump|home> jffs2: attempt to mount non-MTD device 07:01
May 29 08:49:29 <mickeyl> Hertog: ah right, i see it. hmm i'm really clueless where to add the offset to
May 29 08:49:37 <CoreDump|home> so loop doesn't work
May 29 08:49:44 <mickeyl> pb_: how do you deal with that in the hh.org kernel? 
May 29 08:52:30 <Hertog> mickeyl: dev_name is the thing containing the ttyS part, but I don't think it's just a matter of 'add three and thou shalt be content" 
May 29 08:52:52 <mickeyl> Hertog: yeah, it's probably not enough
May 29 08:53:12 <Yog> pb_: setting no_erase=1 somehow worked. the bootloader complained about missing formatting, but it now loads the kernel from my jffs2 image (which then gives a kernel panic because it cannot "mount root fs on 1f:01", but that's another story). But that's a start.
May 29 08:55:44 <Hertog> mickeyl: hmm, couldn't the offset be added based on minor numbers?pxa-tty's start at 67
May 29 08:56:14 <Hertog> mickeyl: or would that be considered 'an even uglier hack' :)
May 29 08:57:18 <mickeyl> Hertog: i'm not sure. i got the patch from http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/attachments/20041124/2f7ff140/pxa-serial-hack-0001.bin and there wasn't more info
May 29 08:58:52 <mickeyl> the respective mail was http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-November/025566.html
May 29 09:00:25 <mickeyl> perhaps the advise from nicolas is a better strategy
May 29 09:00:27 <mickeyl> (next post)
May 29 09:02:51 <Hertog> mickeyl: next->next post gives little hope for a quick solution :)
May 29 09:11:45 <mickeyl> ya
May 29 09:12:03 <mickeyl> at least none with the official blessing
May 29 09:12:47 <Hertog> RK speaks of a patch that he 'might' push, assigning the PXA tty's to ttySA
May 29 09:13:49 <CIA-4> 03zecke123 07bitbake-1.3.0 * r227 10/: Tag Bitbake 1.3.0
May 29 09:13:57 <mickeyl> aah
May 29 09:13:58 <mickeyl> :)
May 29 09:14:22 <Hertog> mickeyl: but then again, that's what (next post) is about I guess (ttySA = amba?)
May 29 09:25:37 <pb_> mickeyl: sorry, deal with what?
May 29 09:25:43 <pb_> Yog: ah, cool
May 29 09:26:34 <mickeyl> pb_: coexistence of 8250-based serial ports and pxa-serial ports. i applied http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/attachments/20041124/2f7ff140/pxa-serial-hack-0001.bin however cardmgr still picks a new port (i.e. a BT card or a GPS card) up as ttyS0
May 29 09:27:15 <pb_> ah.  I'm not sure that we do deal with it, really.  
May 29 09:27:58 <pb_> serial port naming has always been a (famously) sensitive topic in the arm kernel.
May 29 09:28:21 <koen> heh
May 29 09:28:24 <koen> ttySA0?
May 29 09:28:36 <Hertog> that's what RK proposes
May 29 09:28:52 <mithro> SAO!
May 29 09:28:54 <koen> and rmk filtering out *@hp.com
May 29 09:28:57 <pb_> seems reasonable enough, in absence of any joined up strategy for this stuff
May 29 09:29:16 <mickeyl> ok, how would go about doing that?
May 29 09:29:27 <Hertog> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/028847.html
May 29 09:29:28 <pb_> just patch drivers/serial/pxa.c, change its naming.
May 29 09:29:30 <Hertog> this something?
May 29 09:29:55 <pb_> yeah, like that
May 29 09:29:58 <koen> pb_: it does however register as ttyS3, no matter what cardmgr reports
May 29 09:30:34 <Hertog> koen: it reports ttyS3, but that's because (I think) they just add 3 to the var :)
May 29 09:31:07 <koen> I could use it as ttyS3
May 29 09:31:47 <Hertog> koen: mmm, could that be because of this: +       .minor                  = 64 + 3,
May 29 09:32:28 <Hertog> I guess it is, but cardmgr doesn't assign based on minor numbers, it checks which is the first free one, in it's opinion
May 29 09:32:57 <pb_> oh, really?  that's pretty broken.
May 29 09:33:23 <koen> bot on ipaq/2.4 and z/2.6
May 29 09:33:35 <pb_> sure, it wouldn't be machine specific.
May 29 09:33:46 <pb_> has anybody tried with the hotplug-based pcmcia code, rather than cardmgr?
May 29 09:33:55 <pb_> I imagine that ought to work better.
May 29 09:34:04 <mickeyl> good idea,
May 29 09:34:06 <pb_> if it does, maybe we can just not care about the cardmgr problem
May 29 09:34:07 <mickeyl> no time to try that yet
May 29 09:35:05 <pb_> maybe hertog would like to give it a go
May 29 09:35:18 <pb_> I guess you need 2.6.12 plus the appropriate userspace bits
May 29 09:35:45 <Hertog> pb_: that's with pcmciautils instead of pcmcia-cs?
May 29 09:36:08 <pb_> right
May 29 09:37:52 <Hertog> pb_: don't know if that is gonna make a huge difference? Cardmgr is just setting stuff up as the kernel reports it to it. The kernel/driver/module tells "take ttyS0", don't know how much difference it makes changeng userland tools?
May 29 09:38:28 <Hertog> (hmm, if userland looks at major/minor numbers it might just work :))
May 29 09:39:18 <Hertog> userland? is that even the correct term for it? :)
May 29 09:39:46 <pb_> Hertog: eh?  you just told me that cardmgr "checks which is the first free one, in its opinion"
May 29 09:40:01 <pb_> whereas now you seem to be saying that the kernel tells it which device to use, explicitly.
May 29 09:40:09 <pb_> which of those is correct?
May 29 09:40:53 <Hertog> pb_: yeah, but it checks based on what the driver tells it. it does a call to DS_GET_DEVICE_INFO which returns a struct in which the tty-to-be is named.
May 29 09:41:10 <Hertog> pb_: wait a sec ;) DS_GET_DEVICE_INFO is pcmcia-cs isn't it?
May 29 09:41:16 <pb_> yes
May 29 09:41:30 <pb_> pcmcia-utils doesn't use that interface
May 29 09:41:46 <zecke> OT: the Free Bitkeeper client is too limited
May 29 09:41:58 <zecke> it does not even offer the CSEt number in the downloaded ChangeLog
May 29 09:42:00 <pb_> zecke: thanks for the bulletin
May 29 09:42:58 <zecke> :}
May 29 09:43:26 <pb_> bbiab
May 29 09:43:30 * pb_ ->
May 29 09:43:53 <Hertog> ok. so 8250 assigns the good major/minor numbers, (minor 0-2 for PXA, and >=3 for pcmcia), and pcmcia-utils uses these to assign the right ttySX. I'll see if I can get pcmcia-utils to work
May 29 09:44:36 <Hertog> (add 'based on major/minor ' before 'the right ttySX')
May 29 09:56:37 <Hertog> pb_: how hard would it be (re consequences ect) to do it 'the right way', being putting the PXA tty's at ttySA? Since it seems that is the way RK wants it, and I don't think mainline will deviate from that (rather deviate towards that)
May 29 10:27:03 <pb_> Hertog: should be pretty easy.  I'm not sure exactly how much fallout there would be from the names changing, but I guess that since the strongarm machines already use ttySAn, it could be made to work.
May 29 10:56:26 <keturn> okay.  I can actually run configure on my target now.  What should I take from config.file there to put in to CONFIG_SITE?  Everything?  Or is there some way to just narrow it down to things that cross-compiling would miss?
May 29 10:57:45 <pb_> keturn: your best bet is probably to look at the existing site files for other machines, and define the same things that they do.
May 29 10:58:53 <pb_> I guess it would be fairly easy to make a little script that generated a new site file from the existing site/* and a config.cache.
May 29 11:01:25 <keturn> hm.  some site/* have considerably more entries than others.
May 29 11:03:08 <mickeyl> some platforms are used more than others
May 29 11:03:25 <keturn> grep -c samba * says:  i486-linux: 3  i686-linux: 2 x86_64-linux: 1 armeb-linux: 89
May 29 11:05:36 <keturn> there are 93 lines in the config.cache I just generated that have 'samba' in the identifier, and the other 400-some are ac_cv symbols.
May 29 11:09:52 <pb_> site/arm-linux is probably the best one to take as a guide.  that's the platform that gets most testing.
May 29 11:10:14 <pb_> hardly anybody uses sparc, for example, so that site file might well be outdated.
May 29 11:13:29 <zecke|assignment> re
May 29 11:21:27 * france is back (gone 13:20:30)
May 29 11:21:58 <Zero_Chaos> if I promise not to clone from it, will someone tell me the oe-dev bk repository address?
May 29 11:22:24 <Zero_Chaos> (I cloned against the public repository, but I want to build from the dev)
May 29 11:23:00 <koen> bk://oe-devel.bkbits.net/openembedded
May 29 11:23:09 <Zero_Chaos> thanks
May 29 11:23:18 <zecke|assignment> france: wb
May 29 11:23:30 <france> zecke|assignment: thanks!
May 29 11:23:52 <Zero_Chaos> hmm, why can't I "bk pull bk://oe-devel.bkbits.net/openembedded"?
May 29 11:28:29 <CoreDump|home> probably because you need dev access
May 29 11:29:14 <Zero_Chaos> It doesn't seem to let me "bk pull bk://openembedded.bkbits.net/openembedded" either.... am I doing it right?
May 29 11:29:32 <zecke|assignment> Zero_Chaos: did you reject the open logging license?
May 29 11:30:03 <Zero_Chaos> um, I don't think so... it does this:
May 29 11:30:05 <Zero_Chaos> [oe]zaurus@frog ~/src $ bk pull bk://oe-devel.bkbits.net/openembedded
May 29 11:30:05 <Zero_Chaos> pull: cannot find package root
May 29 11:31:19 <CoreDump|home> hmm AFAIK, to "pull" you already need the source tree on your HDD.
May 29 11:31:31 <CoreDump|home> "clone" would copy everything
May 29 11:31:35 <zecke|assignment> ah right
May 29 11:31:42 <CoreDump|home> I'm no bk expert though :)
May 29 11:32:08 <Zero_Chaos> CoreDump|home: you are correct, but I already cloned (bk://openembedded.bkbits.net/openembedded)
May 29 11:32:44 <CoreDump|home> and you've cd'ed into the openembedded folder to pull?
May 29 11:32:52 <Zero_Chaos> doh....
May 29 11:32:57 <Zero_Chaos> um, I was ..
May 29 11:32:58 <Zero_Chaos> thanks
May 29 11:33:20 <CoreDump|home> np :)
May 29 12:06:01 * zecke|assignment is too dumb for procmail
May 29 12:07:50 <pb_> zecke|assignment: procmail is so passé anyway.  if you have exim installed, you can use its builtin filtering.
May 29 12:08:37 <zecke|assignment> I just want something that fscking works ;)
May 29 12:08:50 <zecke|assignment> if 'tinderbox' in To: execute fo...
May 29 12:10:00 <zecke|assignment> exim filters look better
May 29 12:17:00 <zecke|assignment> ~lart zecke
May 29 12:17:00 * ibot farts in zecke's general direction
May 29 12:21:16 * pb_ stabs his nslu2
May 29 12:21:36 <pb_> transferring at 60KB/s over 100Mbps ethernet is no good
May 29 12:24:51 <mickeyl> there's still something wrong with PREFERRED_PROVIDERS
May 29 12:25:15 <mickeyl> say MACHINE=spitz. bbread|grep PREFERRED_PROVIDERS shows me virtual/kernel:openzaurus-pxa27x
May 29 12:25:19 <mickeyl> which is fine
May 29 12:25:20 <mickeyl> however
May 29 12:25:27 <mickeyl> bitbake -nv virtual/kernel attempts to build jlime-whatever
May 29 12:25:48 <zecke|assignment> mickeyl: missing gcc2 assume provided?
May 29 12:26:05 <mickeyl> to. it's not getting recognzied at all
May 29 12:26:07 <mickeyl> it says
May 29 12:26:15 <mickeyl> consider defining PREFERRED_PROVIDER_virtual/kernel
May 29 12:27:16 <pb_> are you setting PREFERRED_PROVIDERS via an override?
May 29 12:27:24 <mickeyl> yes
May 29 12:27:30 <mickeyl> PREFERRED_PROVIDERS_append_spitz
May 29 12:27:42 <mickeyl> i thought zecke's latest patch was supposed to fix taht
May 29 12:27:50 <pb_> let me have a look
May 29 12:27:54 <mickeyl> thanks
May 29 12:28:11 <pb_> I don't think I'm up to date with the latest zeckeware
May 29 12:28:14 <mickeyl> heh
May 29 12:28:17 * pb_ svn update
May 29 12:29:40 <zecke|assignment> hmm
May 29 12:30:40 <pb_> ah, I see, he runs update_data(make.cfg) after parsing
May 29 12:30:43 <pb_> very cunning
May 29 12:30:46 <pb_> I wonder why that isn't working
May 29 12:31:34 <zecke|assignment> pb_: but after having collected the bitbake files
May 29 12:31:40 <pb_> right
May 29 12:32:14 <zecke|assignment> wow my tinderbox shows builds logs
May 29 12:32:25 <pb_> awesome
May 29 12:33:06 <zecke|assignment> too bad it considers "0 out of 0 examples failed" as build error
May 29 12:33:12 <pb_> heh
May 29 12:34:52 <zecke|assignment> OT: It helps to place procmailrc rules in .procmailrc instead of .forward
May 29 12:34:58 <pb_> mickeyl: I don't see anything amiss from eyeballing the code.  I'll have to experiment with it.
May 29 12:35:26 <zecke|assignment> france: I would like to get slowly started in setting up tinderbox.handhelds.org :}
May 29 12:35:28 <mickeyl> pb_: hold on, i've just seen one local diff
May 29 12:35:43 <pb_> fwiw, "bbread" doesn't see the same view of the data as bitbake itself, so the output from that command is not a reliable indicator of what's going on
May 29 12:35:54 <pb_> in this situation, that is
May 29 12:38:13 * mickeyl watches bitbake parsing
May 29 12:38:16 <mickeyl> zzZZzz
May 29 12:38:27 <pb_> :-}
May 29 12:39:19 <mickeyl> "go johnny go"
May 29 12:40:54 <mickeyl> ok, i hereby withdraw all of my accusations. it's too hot for me think clearly. i've missed a local diff. bitbake-1.3.0 is unguilty
May 29 12:41:05 * mickeyl hides in shame and goes washing the dishes
May 29 12:41:34 <pb_> hehe
May 29 12:41:34 <pb_> very good
May 29 12:41:36 <koen> you could come over here and wash the dishes if you are *really* ashamed :)
May 29 12:42:12 * pb_ hands mickeyl an airconditioner
May 29 12:43:56 <ljp> you should move here.. it's cold 10C
May 29 12:47:03 <pb_> he might regret that in 6 months, though
May 29 12:47:58 <ljp> naaa.. thats topless beach season
May 29 12:51:27 <pb_> heh
May 29 12:51:50 * pb_ not sure that topless mickeyl is something to be encouraged
May 29 12:52:24 <reenoo_> heh
May 29 13:04:34 <koen> hey Pigi 
May 29 13:04:38 <Pigi> Ciao all 
May 29 13:04:42 <Pigi> Hi koen.
May 29 13:04:46 <pb_> hi pigi
May 29 13:04:55 <Pigi> koen, too quick for me ;) 
May 29 13:04:58 <Pigi> hi pb_
May 29 13:06:04 * mickeyl confirms that he needs to do some more workout before topless is an option
May 29 13:06:58 <Zero_Chaos> can someone tell me why this happens? (besides the obvious)
May 29 13:06:59 <Zero_Chaos> [oe]zaurus@frog ~/src/build $ bitbake opie-image
May 29 13:07:00 <Zero_Chaos> ERROR: Unable to open conf/bitbake.conf
May 29 13:07:20 <mickeyl> what's your BBPATH ?
May 29 13:07:29 <Zero_Chaos> good question
May 29 13:07:36 <Zero_Chaos> I think I missed that part, thanks
May 29 13:08:33 <reenoo_> hey Pigi 
May 29 13:09:01 <Pigi> hi reenoo_ !
May 29 13:10:34 <Zero_Chaos> mickeyl: thanks, all problems solved
May 29 13:10:54 <mickeyl> glad to hear
May 29 13:13:38 <luke-jr_> Is there already code to make /media/ram to actually a tmpfs at boot?
May 29 13:17:05 <reenoo_> luke-jr_: man fstab
May 29 13:25:17 <luke-jr_> reenoo_: right... but I mean including creating the home/* dirs
May 29 13:25:35 <luke-jr_> which are symlinked from ~*/ramdisk by default
May 29 13:25:40 <cxm> hi, any arm gurus here
May 29 13:26:35 <cxm> sleep.S:40: Error: internal_relocation (type: OFFSET_IMM) not fixed up
May 29 13:26:43 <cxm> I'm getting that from a toolchain I built
May 29 13:26:55 <cxm> any ideas
May 29 13:27:37 <reenoo_> luke-jr_: ah, right. that's taken care of by the pre-session scripts of gpe-login IIRC
May 29 13:28:11 <luke-jr_> reenoo_: ah; so fstab is all that's needed
May 29 13:28:24 <luke-jr_> reenoo_: any reason OE's fstab doesn't have it by default?
May 29 13:29:28 <reenoo_> luke-jr_: dunno. fstab is MACHINE specific. so it depends on what MACHINE you're building for I guess
May 29 13:30:02 <luke-jr_> hmm
May 29 13:30:05 <reenoo_> luke-jr_: s/it/whether your fstab contains that/
May 29 13:30:10 <luke-jr_> collie and poodle's fstab has it
May 29 13:30:46 <luke-jr_> and ipaq stuff
May 29 13:32:02 <luke-jr_> commented in collie/poodle, actually
May 29 13:32:15 <luke-jr_> almost as if there's a reason for it :|
May 29 13:32:45 <luke-jr_> who maintains base-files?
May 29 13:32:55 <koen> check MAINTAINER
May 29 13:33:13 <luke-jr_> koen: there is none
May 29 13:33:22 <koen> then there isn't a maintainer
May 29 13:33:54 <luke-jr_> -.-
May 29 13:34:32 <reenoo_> luke-jr_: ah, right. "# we use a non-volatile ramdisk, see /etc/init.d/ramdisk" speaks for itself doesn't it?
May 29 13:35:11 <luke-jr_> if I noticed that, it would ;)
May 29 13:36:53 <luke-jr_> (or if anything was mounted on it)
May 29 13:38:09 <reenoo_> best talk to our resident Z experts then. I don't know how exactly the non-volatile ramdisk works
May 29 13:39:22 <luke-jr_> I'm guessing it aborts on c7x0
May 29 13:39:26 <luke-jr_> if test -z "$RAM_MTD_NO"; then exit 0; fi
May 29 13:41:48 <luke-jr_> yep
May 29 13:45:20 <luke-jr_> CoreDump|home: hey
May 29 13:45:36 <CoreDump|home> luke-jr_: ho
May 29 13:45:52 <luke-jr_> CoreDump|home: you seem to mess w/ c7x0's fstab a bit...
May 29 13:46:01 <CoreDump|home> collie actually
May 29 13:46:10 <luke-jr_> ChangeLog says c7x0 also =p
May 29 13:46:20 <luke-jr_> oops
May 29 13:46:21 <CoreDump|home> what did i do?
May 29 13:46:27 <luke-jr_> nothing
May 29 13:46:33 <luke-jr_> but it needs a ramdisk mount =p
May 29 13:46:43 <luke-jr_> tmpfs           /media/ram  tmpfs  defaults     0  0
May 29 13:46:59 <CoreDump|home> doesn't have one? hmm
May 29 13:47:03 <luke-jr_> it seems to be either you or zecke... and you've done more changes =p
May 29 13:47:04 <luke-jr_> nope
May 29 13:47:13 <luke-jr_> nor does the ramdisk initscript do anything on c7x0
May 29 13:47:17 <CoreDump|home> heh
May 29 13:47:42 <luke-jr_> so all the c7x0 are in theory logging X stuff to jffs2
May 29 13:48:03 <CoreDump|home> in which package hides fstab again?
May 29 13:48:11 <luke-jr_> (likely to be the case, I just haven't tested)
May 29 13:48:48 <luke-jr_> base-files
May 29 13:48:57 <luke-jr_> openembedded/packages/base-files/base-files/c7x0/fstab
May 29 13:49:02 <CoreDump|home> thx
May 29 13:49:15 <luke-jr_> I'd check the C3000/C1000 also
May 29 13:49:16 <CoreDump|home> and entering the above line fixes the problem?
May 29 13:49:22 <luke-jr_> Not 100% sure yet
May 29 13:49:26 <luke-jr_> 1 sec and I'll let you know
May 29 13:49:33 <CoreDump|home> ok :)
May 29 13:49:56 <luke-jr_> rebooting the Z...
May 29 13:52:24 <luke-jr_> yep
May 29 13:52:35 <luke-jr_> what's with the symlink in ~/ramdisk, tho?
May 29 13:52:47 <luke-jr_> (it's not new, so shouldn't matter)
May 29 14:01:17 <CIA-4> 03CoreDump 07 * r1.3444 10openembedded/packages/base-files/base-files_3.0.14.bb: base-files: bump RP
May 29 14:01:21 <CIA-4> 03CoreDump 07 * r1.3443 10openembedded/packages/base-files/base-files/c7x0/fstab: c7x0 fstab; Add /media/ram (tmpfs) Courtesy luke-jr
May 29 14:02:03 <pb_> bad news for RP
May 29 14:02:47 <Spyro> guys... whats conf/bitbake.conf ?
May 29 14:02:57 <Spyro> I updated bitbake and now I cant build :)
May 29 14:03:04 <koen> heh
May 29 14:03:16 <Pigi> ehehe
May 29 14:03:32 <koen> pb_: but I bet he wouldn't notice a bump while playing with his 770
May 29 14:03:33 <Pigi> "welcome... to the real world"
May 29 14:05:21 <Spyro> anyone ?
May 29 14:05:52 <pb_> koen: heh
May 29 14:06:21 <zecke> good nite
May 29 14:06:25 <CoreDump|home> bleh, I'be been wondering what you are talking about. Now I see heh
May 29 14:06:26 <koen> 'night zecke 
May 29 14:06:29 <pb_> night zecke
May 29 14:06:33 <CoreDump|home> n8 ne
May 29 14:06:37 <CoreDump|home> n8 zecke 
May 29 14:06:37 <Pigi> nite zecke 
May 29 14:07:15 <luke-jr_> what bad news? o.O
May 29 14:07:23 <Pigi> Spyro, have you also updated the whole openembedded stuff ?
May 29 14:07:27 <CoreDump|home> <CIA-4> CoreDump  * r1.3444 openembedded/packages/base-files/base-files_3.0.14.bb: base-files: bump RP
May 29 14:07:29 <Spyro> ah nm. I had a bad path
May 29 14:07:39 <CoreDump|home> luke-jr_: s/RP/PR
May 29 14:07:55 <Spyro> wow, the handling bitbake files bit is way better now
May 29 14:08:10 <luke-jr_> <pb_> bad news for RP
May 29 14:08:30 <luke-jr_> oh heh
May 29 14:08:34 <CoreDump|home> :)
May 29 14:09:09 * luke-jr_ bumps RP
May 29 14:09:12 <luke-jr_> =p
May 29 14:14:30 * keturn tries to untangle this autoconf mess in which it decided it could use dirent64 without defining _GNU_SOURCE or _LARGEFILE64_SOURCE.  And why didn't it define those, anyway?
May 29 14:20:29 <keturn> it defines those after a native ./configure, but not cross.
May 29 14:21:30 <pb_> heh, oh dear
May 29 14:22:37 <Spyro> since when was gpe-confd needed in a task-bootstrap ?
May 29 14:23:19 <Pigi> ERROR: 'NoneType' object has no attribute 'getVar' while parsing /ext/ambient/openembedded/packages/sharp-binary-only/sharp-aticore.bb
May 29 14:23:25 <Pigi> What's about that ?
May 29 14:24:03 <zecke> Pigi: broken bbfile
May 29 14:24:16 <Pigi> ok thx.
May 29 14:24:22 <zecke> tinderboxing didn't allow me to fix it yet
May 29 14:25:16 <Pigi> just a tought about the new bitbake. It take a long time between "Building Provider Hash" and the start of operation. 
May 29 14:25:25 <Pigi> I have traced it and see that it works hard
May 29 14:26:03 <Pigi> Wouldn't  be bettere to have a couple of messages informing peoples about those other phases ?
May 29 14:26:18 <Pigi> So I ( they ) don't think that is simply hang ?
May 29 14:29:35 <CIA-4> 03mickeyl * r228 10bitbake/bin/bitbake: 
May 29 14:29:35 <CIA-4> misc. refactoring bits for bin/bitbake:
May 29 14:29:35 <CIA-4>  - remove executeOneBB
May 29 14:29:35 <CIA-4>  - add tryBuildPackage
May 29 14:29:35 <CIA-4>  - add more docstrings
May 29 14:29:35 <CIA-4>  - less abbrevations
May 29 14:29:37 <CIA-4>  - s/buildPackage/buildProvider/
May 29 14:30:05 <zecke> mickey|tv: could we create more tests in bitbake?
May 29 14:30:45 <mickey|tv> zecke: would be a good idea
May 29 14:31:07 <mickey|tv> perhaps a test.conf with some params
May 29 14:31:17 <mickey|tv> and then using this test.conf to test various internal functios
May 29 14:31:21 <mickey|tv> functions even
May 29 14:31:44 <mickey|tv> sooner or later we should merge make.py back into bin/bitbake _or_ factor out more stuff out of the bitbake command line utility into the make module
May 29 14:32:33 <pb_> yeah, the split is a bit arbitrary right now
May 29 14:32:44 <pb_> I think the easiest thing would be to just dump make.py back into bin/bitbake
May 29 14:33:19 <mickey|tv> easy yes, however bitbake is already too complicated imho
May 29 14:33:30 <zecke> I would prefer to move it 'back' to the bb module
May 29 14:33:50 <CIA-4> 03mickeyl * r229 10bitbake/lib/bb/shell.py: 
May 29 14:33:50 <CIA-4> major update:
May 29 14:33:50 <CIA-4> - improve registerCommand
May 29 14:33:50 <CIA-4> - build, clean, and rebuild no longer work on providees or bbfiles, but just on providees
May 29 14:33:50 <CIA-4> - filebuild, fileclean and filerebuild work on bbfiles
May 29 14:33:51 <CIA-4> - add which 'providee'
May 29 14:34:00 <pb_> mickey|tv: I'm not sure that concealing parts of it in make.py really makes it any simpler.
May 29 14:35:04 <mickey|tv> pb_: possible, however it's not just pasting it into bitbake, because we use the make module namespace for some values which would need to be added into a dedicated class then
May 29 14:35:08 <keturn> So under what circumstances would configure-stuff not get saved in cache-file?
May 29 14:35:39 <pb_> mickey|tv: true, or we could just do a global s/make.//
May 29 14:35:42 <keturn> I'm staring at configure.in and for some things it spat out a cached value, and for other things it didn't, and I really need to set one of those other things.
May 29 14:36:08 <mickey|tv> pb_: that doesn't work. it's python, we would need to distinguish between reading and writing variables and cluster 'global' statements all over the place
May 29 14:36:28 <mickey|tv> pb_: i will take care about merging make eventually
May 29 14:36:31 <pb_> mickey|tv: the "make." stuff isn't used by anything other than bitbake.
May 29 14:36:32 <mickey|tv> but it needs to be thought out
May 29 14:37:02 <zecke> pb_: hmm 
May 29 14:37:15 <mickey|tv> yes i know - that doesn't make a difference though. if you refer to a variable from a function that previously was in a dedicated namespace you now add a local binding
May 29 14:37:15 <pb_> iirc, the only reason we have the "make" namespace at all is because that stuff was originally split out from oemake into a separate module.
May 29 14:37:47 <zecke> ok keep me updatet
May 29 14:38:03 <zecke> mickey|tv: besides the shell, I would like to focus on improving the parser and the cache
May 29 14:38:16 * zecke didn't even start his assignment
May 29 14:38:30 <keturn> oh, it uses AC_CACHE_CHECK for some.
May 29 14:38:34 <mickey|tv> zecke: yeah, the parser needs some love (read speed) next :D
May 29 14:38:56 <pb_> mickey|tv: ah, okay.  I didn't really understand anything in the last paragraph you wrote, so I guess I will shut up now.
May 29 14:38:57 <pb_> heh
May 29 14:39:04 <zecke> mickey|tv: TINDER_TEST = "1" # Should tinder test be run
May 29 14:39:14 <zecke> mickey|tv: bb.data.getVar('TINDER_TEST', d)
May 29 14:39:23 <zecke> mickey|tv: guess what I got as value
May 29 14:39:42 <pb_> zecke: "1" # Should tinder test be run
May 29 14:39:45 <mickey|tv> pb_: heh. see: def foo: make.bar = 1 always is fine
May 29 14:39:54 <mickey|tv> we would need to substitute that with
May 29 14:39:58 <zecke> pb_: righto
May 29 14:39:59 <mickey|tv> def foo: global bar bar = 1
May 29 14:40:17 <mickey|tv> which is ugly. the make namespace was nice to group some related variables and reduce the number of globals
May 29 14:40:25 <mickey|tv> so i just factor them into a common class 
May 29 14:40:29 <mickey|tv> or struct, for that matter
May 29 14:40:38 <pb_> mickey|tv: surely if "bar" is a global, defined in the same file, you can just refer to it by name?
May 29 14:40:54 <mickey|tv> pb_: not by writing
May 29 14:41:07 <pb_> ah
May 29 14:41:16 <mickey|tv> without the global statement you just add a local binding when accessing from a function
May 29 14:41:23 <mickey|tv> this is a python thingy
May 29 14:41:33 <pb_> right, I see
May 29 14:41:34 <pb_> crazy python
May 29 14:42:48 <zecke> kergoth: I use bitbake (with a special base.bbclass) to function as tinder-client
May 29 14:48:15 <Spyro> how can bb be trying to build ipkg-utils-native-1.6cvs20050529 when my openembedded stuff is about two weeks old ?
May 29 14:49:22 <koen> because it fetches the latest cvs
May 29 14:49:50 <koen> unless you do CVSDATE_ipkg-utils-native=20050101 or something
May 29 14:49:54 <mickey|tv> sounds like you don't set one of our DISTRO configurations
May 29 14:49:55 <Spyro> ok next Q... why does it fail to fetch it ? :)
May 29 14:50:03 <mickey|tv> our DISTRO
May 29 14:50:07 <Spyro> mickey|tv: should I have ?
May 29 14:50:08 <mickey|tv> 's set a fixed CVSDATE
May 29 14:50:21 <mickey|tv> in almost all cases it makes sense to build with a DISTRO set, yes
May 29 14:50:34 <Spyro> ok, so whats a 'recommendd' setting for that ?
May 29 14:50:38 <mickey|tv> openzaurus-3.5.4
May 29 14:50:41 <mickey|tv> familiar-0.9.0
May 29 14:50:44 <mickey|tv> ...
May 29 14:50:57 <Spyro> whats the practical difference ?
May 29 14:51:08 <mickey|tv> diff 
May 29 14:51:17 <mickey|tv> distro policy settings
May 29 14:51:27 <mickey|tv> preferred versions, soft float or hard float,e tc.
May 29 14:51:31 <Spyro> where are those kept ?
May 29 14:51:36 <mickey|tv> conf/distro/*
May 29 14:52:14 <Spyro> ta
May 29 14:53:01 <mickey|tv> hmm
May 29 14:53:07 <mickey|tv> who needs /media/ram ?
May 29 14:53:12 <mickey|tv> isn't /tmp enough ?
May 29 14:53:36 <Spyro> one would think so
May 29 14:54:46 <reenoo_>  /media/ram is a non-volatile ramdisk on some of the Zs isn't it? why not make use of that?
May 29 14:55:00 <mickey|tv> uhm
May 29 14:55:04 <mickey|tv> it has been added to the c7x0 fstab
May 29 14:55:11 <mickey|tv> the c7x0 never used a ramdisk
May 29 14:55:14 <mickey|tv> no matter if volatile or not
May 29 14:55:24 <mickey|tv> the collie uses a ramdisk
May 29 14:55:27 <mickey|tv> that's the only model
May 29 14:55:47 <mickey|tv> because it's the only model where we have different kernels with different memory/storage splits
May 29 14:55:53 <mickey|tv> it just doesn't make sense on other models
May 29 14:57:13 <mickey|tv> CoreDump|home: this change is bogus. mind me to revert?
May 29 14:57:26 <Pigi> time to sleep. Nite all
May 29 14:57:46 <reenoo_> mickey|tv: you do know that GPE writes logs there, don't you?
May 29 14:57:59 <mickey|tv> GPE writes logs to /media/ram?
May 29 14:59:00 * CoreDump|home looks at luke-jr_ 
May 29 14:59:23 <mickey|tv> renoo: sounds like GPE is broken then. isn't /var/log (sic!) or /tmp dedicated to contain logs ?
May 29 14:59:28 <reenoo_> mickey|tv: to /home/$USER/ramdisk which is a symlink to /media/ram/home/$USER/
May 29 14:59:36 <reenoo_> mickey|tv: no
May 29 14:59:55 <reenoo_> mickey|tv: not for .xsession-errors and stuff
May 29 15:00:43 <mickey|tv> what makes .xsession-errors so special ?
May 29 15:02:18 <Spyro> its still trying to do that particular date
May 29 15:02:29 <Spyro> NOTE: package ipkg-utils-native-1.6cvs20050529-r4: task do_unpack: started
May 29 15:02:29 <Spyro> NOTE: Unpacking /home/ian/Download/bbsources/ipkg-utils_cvs.handhelds.org__20050529.tar.gz to /home/ian/projects/openembedded/stuff/tmp/work/ipkg-utils-native-1.6cvs20050529-r4/
May 29 15:02:29 <Spyro> tar: /home/ian/Download/bbsources/ipkg-utils_cvs.handhelds.org__20050529.tar.gz: Cannot open: No such file or directory
May 29 15:02:29 <Spyro> tar: Error is not recoverable: exiting now
May 29 15:04:53 <reenoo_> mickey|tv: does a user have write access in /var/log? I don't think so
May 29 15:05:22 <Spyro> hm. it isnt even trying to download the file. thats odd.
May 29 15:07:10 <mickey|tv> reenoo_: no, that's right
May 29 15:07:26 <mickey|tv> i still question /home/$USER/ramdisk
May 29 15:08:13 <mickey|tv> anyway base filesystem issues should be discusses on the list
May 29 15:08:17 <mickey|tv> not just changed because of one request
May 29 15:08:26 <reenoo_> huh?
May 29 15:08:39 <reenoo_> all ipaqs have that entry in fstab
May 29 15:09:09 <mickey|tv> may be or may not
May 29 15:10:23 <luke-jr_> mickey|tv: .xsession-errors
May 29 15:10:26 <pb_> reenoo_: true, but other devices are not obliged to do the same
May 29 15:11:23 <luke-jr_> Is there a problem with having ~/ramdisk actually be a ramdisk?
May 29 15:11:44 <Spyro> hjow can I find what is causing a particular package to be built ?
May 29 15:11:46 <pb_> No, but it would be a bit wasteful to mount a separate ramdisk under every home directory.
May 29 15:12:07 <luke-jr_> it doesn't
May 29 15:12:23 <luke-jr_> all homedirs symlink ramdisk to /media/ram/home/username
May 29 15:12:33 <mickey|tv> Spyro: you can use bitbake -nv and then you'll see the paths to a certain dependency
May 29 15:12:52 <mickey|tv> do they? since when? by what script? 
May 29 15:13:00 <luke-jr_> some GPE scripts, I think
May 29 15:13:09 <luke-jr_> or so someone told me a while ago
May 29 15:13:15 <mickey|tv> very well. you see you can't just add a mountpoint to a filesystem without knowing things for sure
May 29 15:13:24 <mickey|tv> we are trying to preserve a certain quality here
May 29 15:13:24 <reenoo_> pb_: right. but currently GPE assumes /media/ramdisk to be a tmpfs or a non-volatile ramdisk.
May 29 15:13:38 <mickey|tv> if things are just changed, then we generate lots of potential bug hunt waste of time
May 29 15:13:45 <mickey|tv> that's not how it's supposed to be
May 29 15:13:47 <reenoo_> mickey|tv: calm down a bit. luke-jr_ is right about that.
May 29 15:13:53 <luke-jr_> and since some devices have a non-tmpfs ramdisk, it makes sense to use /media/ram instead of /var
May 29 15:15:08 <mickey|tv> no need to calm down here. it touches a principle. how are we supposed to work together on a common distribution if we do such things? 
May 29 15:15:29 <luke-jr_> mickey|tv: also, CoreDump and zecke are the only ones who have changed the c7x0 fstab in BK's ChangeLog, so who am I supposed to talk to about it?
May 29 15:15:45 <luke-jr_> I would have gone after a MAINTAINER first, if there was one
May 29 15:15:50 <pb_> reenoo_: sure, and I think it's desirable to have a ramdisk available on all systems (even if it's just a subdirectory under /var or /tmp).  But "all ipaqs do <x>" is never a good argument for making it into a more general policy.
May 29 15:16:19 <mickey|tv> luke-jr_: for such things we have openzaurus-devel
May 29 15:16:33 <luke-jr_> mickey|tv: used for OE in general?
May 29 15:16:59 <mickey|tv> luke-jr_: well, that's the mailing list of the openzaurus developers
May 29 15:17:13 <mickey|tv> c7x0 fstab is not a general thing, so oe@handhelds.org would be a bit over the top
May 29 15:17:26 <mickey|tv> imo
May 29 15:17:46 <luke-jr_> Are there OE/OZ devs not on IRC?
May 29 15:17:55 <mickey|tv> of course
May 29 15:18:07 <CoreDump|home> luke-jr_: your are talking to them :)
May 29 15:18:12 <luke-jr_> I wasn't aware of that-- I'll subscribe to those lists, then
May 29 15:18:20 <luke-jr_> CoreDump|home: I am? O.o
May 29 15:18:42 * CoreDump|home introduces luke-jr_ to mickey|tv pb_ reenoo_ etc ;)
May 29 15:18:51 <luke-jr_> they're not on IRC?
May 29 15:18:56 <CoreDump|home> ah
May 29 15:19:06 <pb_> apparently not
May 29 15:19:06 <CoreDump|home> i missed the "not"
May 29 15:19:18 <luke-jr_> heh
May 29 15:19:23 <treke|home> I dont see schurig here
May 29 15:19:54 <treke|home> nor CP
May 29 15:19:56 <mickey|tv> IRC is good for ad-hoc decisions, but for things which may affect other things I prefer mailing lists, where one can actually take the time to think about an issue
May 29 15:19:57 <luke-jr_> the MLs are via SF? (don't see a link from oz.org)
May 29 15:20:08 <mickey|tv> yes, openzaurus-devel@lists.sf.net
May 29 15:20:17 <reenoo_> pb_: agreed
May 29 15:20:26 <CoreDump|home> so, what do we do? back out the cset or does having /media/ramdisk make sence on a c7x0
May 29 15:20:33 <luke-jr_> mickey|tv: how about oe?
May 29 15:21:04 <luke-jr_> CoreDump|home: I think it makes sense... it works; if it's preferable, I'll start a ML thread instead...
May 29 15:21:06 <mickey|tv> luke-jr_: oe is mainly for packages since packages land in all distributions made out of oe. and of course, for build classes etc.
May 29 15:21:23 <reenoo_> mickey|tv: last time I checked OZ wasn't the only distro shipping c7x0 images. why do you want to discuss things on openzaurus-devel?
May 29 15:21:47 <mickey|tv> reenoo_: the fact that familiar built c7x0 images was disputable as well
May 29 15:22:04 <mickey|tv> if we are to merge we have to agree on some things. 
May 29 15:22:04 * luke-jr_ builds c7x0 images =p
May 29 15:22:14 <mickey|tv> not doing things without discussing is one basic issue
May 29 15:22:28 <mickey|tv> if we can't do that we better continue seperate development lines
May 29 15:22:52 <reenoo_> mickey|tv: the point is.. do you expect familiar people to be subscribed to openzaurus-devel?
May 29 15:23:18 <mickey|tv> reenoo_: start getting of your "familiar" people vs. "openzaurus" poeple. 
May 29 15:23:24 <mickey|tv> that's class thinking
May 29 15:23:33 <mickey|tv> i dunno what you want to express with that
May 29 15:23:49 <mickey|tv> familiar and openzaurus have been essentially the same since long.
May 29 15:23:59 <mickey|tv> we devided into hardware platforms
May 29 15:24:05 <mickey|tv> and even that we want to stop now
May 29 15:24:40 <luke-jr_> so should I subscribe to any MLs other than openzaurus-devel?
May 29 15:24:44 <mickey|tv> i'm subscribe to familiar because familiar is a distribution built out of OE
May 29 15:24:45 <reenoo_> I know and I'm not questioning that. but I don't understand why you want to discuss MACHINE specifc things on a DISTRO specific ML if you want to put it that way
May 29 15:25:06 <mickey|tv> that's essentially our misunderstanding. i see familiar as the ipaq list
May 29 15:25:10 <mickey|tv> and openzaurus as the zaurus list
May 29 15:25:15 <mickey|tv> since our distributions are the same
May 29 15:25:42 <treke|home> the key difference between OZ and familiar are the MACHINE
May 29 15:27:30 <mickey|tv> anyway it's late - g'night
May 29 15:27:34 <luke-jr_> ...
May 29 15:27:38 <pb_> mickey|tv: good night
May 29 15:27:43 <reenoo_> 'nighht mickey|zzZZzz 
May 29 15:27:53 <reenoo_> 'night even
May 29 15:28:18 <luke-jr_> should I subscribe to any general OE MLs? should I start a thread on tmpfs /media/ram? if so, which list?
May 29 15:29:04 <pb_> I think you should start that thread on the openzaurus list, as mickey suggested.
May 29 15:29:32 <CIA-4> 03CoreDump 07 * r1.3445 10openembedded/packages/base-files/base-files/c7x0/fstab: c7x0 fstab: back out previous cset on request...
May 29 15:29:34 <luke-jr_> pb_: ok; is there an OE list to subscribe to?
May 29 15:29:42 <pb_> yes, oe@handhelds.org
May 29 15:32:57 <luke-jr_> k
May 29 15:35:12 <aboeglin> Err, it seems hostme.bkbits.net is dropping connexions from my IP address...
May 29 15:36:38 <pb_> that's very sad
May 29 15:36:39 <aboeglin> Does this happen often ? was using sourcepuller a bad idea ?
May 29 15:38:22 <aboeglin> and the latest snapshot is one month old. aren't they build any longer ?
May 29 15:39:38 <treke|home> no
May 29 15:39:39 <treke|home> they aren't
May 29 15:39:40 <luke-jr_> how's that
May 29 15:40:03 <luke-jr_> (my email to oz-devel)
May 29 15:44:31 <aboeglin> So, the only way to get oe is through bitkeeper :-/
May 29 15:44:55 <luke-jr_> aboeglin: use bk_client
May 29 15:46:48 <aboeglin> luke-jr_: I tried, but y connection seems to be dropped (strace sfioball shows it hangs on connect call)
May 29 15:47:34 <luke-jr_> um
May 29 15:47:39 <luke-jr_> why are you using sfioball?
May 29 15:47:46 <luke-jr_> there's 'update'
May 29 15:48:14 <luke-jr_>  update bk://oe-devel.bkbits.net:8080/openembedded openembedded
May 29 15:48:41 <luke-jr_> (oe-devel doesn't allow sfioball)
May 29 15:48:51 <aboeglin> I can't even access www.bkbits.net on port 80
May 29 15:49:02 <luke-jr_> good thing that doesn't use port 80 then, eh?
May 29 15:49:27 <aboeglin> no, but my point is that it seems they filtered my IP
May 29 15:49:36 <luke-jr_> what'd you do?
May 29 15:49:47 <dhr> I have not signed up for bk, and don't think I will.  Are you saying that I cannot get the source any more?
May 29 15:49:49 <aboeglin> I just tried sourcepuller 0.2
May 29 15:50:07 <luke-jr_> aboeglin: what's sourcepuller?
May 29 15:50:14 <luke-jr_> dhr: signed up for bk?
May 29 15:50:18 <reenoo_> aboeglin: sounds like you're having network issues. I don't think there's anything we can do about that. best talk to your ISP or bitmover
May 29 15:50:19 <luke-jr_> dhr: I never signed up for anything
May 29 15:50:25 <dhr> agreed to license
May 29 15:51:01 <luke-jr_> dhr: something wrong w/ BSD license?
May 29 15:51:20 <dhr> bk license includes non-compete language.
May 29 15:51:25 <CoreDump|home> treke|home: is there a special reason why snapshots are no longer generated?
May 29 15:51:28 <luke-jr_> not the open source bk client
May 29 15:51:29 <dhr> that's not BSD.
May 29 15:51:51 <aboeglin> dhr : there is a no-license & open source pull-only client : http://www.bitmover.com/bk-client.shar
May 29 15:52:11 <dhr> I didn't know that.
May 29 15:52:54 <dhr> Does it let you see the change history ("metadata")?
May 29 15:53:05 <luke-jr_> it has a ChangeLog
May 29 15:54:46 <dhr> That's good!
May 29 15:56:56 <reenoo_> 'night all
May 29 16:11:15 <Spyro> hrm. bitbake appears to be failing to download ANY CVS stuff
May 29 16:12:10 <luke-jr_> update?
May 29 16:13:26 <Spyro> its a latest SVN bitbake...
May 29 17:10:47 <aboeglin> Spyro: It's working fine here with revision 229 (just did a svn update)
May 29 17:19:40 <BigAl> morning
May 29 17:23:53 <Spyro> do I need to update my openembedded profiles too?
May 29 17:32:45 <aboeglin> Err in the config-guess-uclibc.patch of gnu-config, it's written "updated to 20050516", but when I run 'bitbake gpe-image' using familiar 0.8.2 as DISTRO in my local.conf, it fetches gnu-config-native-0.1cvs20050331-r3 ... I guess I should get the falimiar tagged version of openembedded data ? but how can I see the list of available tags with bk_client ?
May 29 17:36:23 <BigAl> I think you need to change the CVSDATE variable
May 29 17:48:45 <treke|home> CoreDump|afk: because there is no point in generating them
May 29 17:49:27 <dhr> why no point?\
May 29 17:49:37 <treke|home> just download the client 
May 29 17:50:44 <treke|home> wow zautrix is a bigger asshole than I thought
May 29 17:55:21 <dhr> convincing demonstration?
May 29 18:05:16 <CoreDump|afk> treke-: what did he do this time?
May 29 18:07:12 <treke|home> Apparantly his app not compiling on fedora is a "feature"
May 29 18:11:37 <CoreDump|afk> heh
May 29 18:13:21 <luke-jr_> lol
May 29 18:13:49 <CoreDump|afk> n8 all
May 29 19:41:53 <Zero_Chaos> I just brought my build environment up, fresh and clean, when I run "bitbake opie-image" it fails.  Seems odd but it doesn't build glibc or gcc before it fails (nor does it fail on either of these).  I tryed to built glibc and gcc but gcc fails.  What do I need to build before trying to build opie-image?
May 29 19:56:08 <luke-jr_> bitbake should handle dependencies...
May 29 19:57:36 <Zero_Chaos> ahh, but it is not... (fully)
May 29 19:58:10 <luke-jr_> what error?
May 29 19:58:12 <luke-jr_> use pastebin.ca
May 29 20:06:20 <Zero_Chaos> I just updated, and told it to "bitbake -k gcc opie-image" so when it errors, I'll let you know...
May 29 20:11:06 <luke-jr_> um
May 29 20:11:10 <luke-jr_> drop the -k and gcc
May 29 20:11:45 <Zero_Chaos> sorry to scroll but... do I need all this in my local.conf to build for collie:
May 29 20:11:49 <Zero_Chaos> ASSUME_PROVIDED = "virtual/${TARGET_PREFIX}gcc virtual/libc"
May 29 20:11:50 <Zero_Chaos> # Select between multiple alternative providers, if more than one is eligible.
May 29 20:11:50 <Zero_Chaos> PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
May 29 20:11:50 <Zero_Chaos> PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-qpe"
May 29 20:11:50 <Zero_Chaos> PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
May 29 20:11:52 <Zero_Chaos> PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
May 29 20:11:55 <Zero_Chaos> PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"
May 29 20:12:07 <luke-jr_> ...
May 29 20:12:10 <luke-jr_> pastebin.ca exists
May 29 20:12:22 <luke-jr_> nor should any of that be needed
May 29 20:12:35 <luke-jr_> in fact, I think that would break it if anything
May 29 20:12:50 <Zero_Chaos> none of that? it was there and uncommented so I left it alone....
May 29 20:12:59 <luke-jr_> um
May 29 20:13:02 <luke-jr_> it was there from what?
May 29 20:13:26 <Zero_Chaos> local.conf.sample
May 29 20:13:53 <luke-jr_> ASSUME_PROVIDED certainly isn't
May 29 20:14:14 <Zero_Chaos> that one was commented out, but I thought that was to build collie kernels
May 29 20:14:34 <Zero_Chaos> of course, as I read over it, I realize I'm a moron
May 29 20:14:43 <Zero_Chaos> so all those should be commented, right?
May 29 20:15:07 <luke-jr_> PREFERRED should be safe
May 29 20:15:28 <luke-jr_> you only need the 2.95 ASSUME_PROVIDED line for a 2.4 kernel
May 29 20:15:48 <Zero_Chaos> yeah, I've got that.  So should I leave prefered, or comment it?
May 29 20:15:59 <luke-jr_> leave the preferred stuff
May 29 20:16:05 <Zero_Chaos> thanks
May 29 20:16:22 <luke-jr_> If 2.4 kernel: ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95"
May 29 20:16:53 <Zero_Chaos> yeah, I've got that in there now...it was that first ASSUME that was likely messing it up.
May 29 20:16:58 <luke-jr_> http://www.cs.wisc.edu/~lenz/zaurus/ has 2.6 status info
May 29 20:17:39 <Zero_Chaos> I have a 5500, no 2.6 for me :-(
May 29 20:18:20 <luke-jr_> that site is 5500 2.6 status, I mean =p
May 29 20:18:47 <Zero_Chaos> I was already reading it.... but last I checked the kernel had a long way to go.  I can't wait...
May 29 20:22:28 <Zero_Chaos> out of curiousity, I find that the cow patches don't apply (the ones from the wiki), is there another location or have new cow patches not been released...
May 29 20:23:21 <luke-jr_> COW is no longer supported
May 29 20:23:31 <luke-jr_> if you enable CACHE, bitbake won't keep stuff in RAM
May 29 20:23:43 <dhr> COW?  Copy On Write?
May 29 20:23:47 <luke-jr_> dhr: right
May 29 20:23:50 <[g2]> ~cow
May 29 20:23:51 <ibot> I am a cow, hear me moo. I eat grass and weigh twice as much as you.
May 29 20:23:55 <luke-jr_> ~bbcow
May 29 20:23:57 <ibot> hmm... bbcow is a couple patches for bitbake and openembedded to use copy-on-write for the metadata handling.  It greatly reduces memory consumption.  Get them at http://www.frankengul.org/~seb/cowbb/. now obsolete
May 29 20:24:36 <luke-jr_> Just enable CACHE and it won't eat much RAM at all
May 29 20:25:11 <Zero_Chaos> thank you, cache has been enabled.
May 29 20:25:36 <Zero_Chaos> without the cow patches when I last used oemake it would fail miserably
May 29 20:25:43 <Zero_Chaos> I only have like 410 RAM
May 29 20:25:49 <luke-jr_> there is no more oemake ;)
May 29 20:26:04 <Zero_Chaos> I know... but that was when I last used OE
May 29 20:26:06 <luke-jr_> I have 1 GB of RAM and I needed COW to get bitbake to use a sane amount
May 29 20:26:11 <luke-jr_> but CACHE solves that now
May 29 20:26:57 <Zero_Chaos> great
May 29 20:27:16 <Zero_Chaos> it all seems working properly now, thanks for your advice luke-jr_ 
May 29 20:27:27 <luke-jr_> yw
May 29 20:45:34 <robert_> hi all
May 29 20:53:40 <robert_> when i built busybox, i found some symlinks were installed to sbin/ or /usr/bin or /usr/sbin. how to install those symlinks to bin/ ?
May 29 20:59:27 <[g2]> robert_, it's a rough crowd in here. I'm waiting for a compile of a new kernel and it's quiet so I'll say last I looked there was a config option in busybox for /bin
May 29 20:59:32 <[g2]> but it's been a while
May 29 21:01:46 <robert_> [g2]:maybe some are sleeping
May 29 21:04:25 <[g2]> robert_, actually they are a very busy extremely hard working crowd.  I think they expect you to do some research to find something like that
May 29 23:44:09 <robert_> [g2]: i have solved it
**** ENDING LOGGING AT Sun May 29 23:59:56 2005