**** BEGIN LOGGING AT Mon Sep 03 02:59:56 2007
Sep 03 03:00:00 <interfaith> angstrom root password anyone ?
Sep 03 03:06:18 <interfaith> how to recompile rootfs after changing /rootfs/etc/passwd ?
Sep 03 03:06:53 <interfaith> bitbake imagename -c compile -f ?
Sep 03 05:49:02 <flux__> hello :) 
Sep 03 05:50:46 <flux__> i installed oe/bitbake as it is said in http://www.openembedded.org/wiki/GettingStarted . i did a "bitbake sudo" for my zaurus/spitz which runs Angstrom
Sep 03 05:51:24 <flux__> when i "ipkg install sudo_armv5te.ipk ", i get this message :   ipkg: fork failed    segmentation fault
Sep 03 05:51:59 <flux__> does anyone know where i should look to find a solution and be able to install sudo ?
Sep 03 05:59:32 <flux__> ram problem, excuse me.
Sep 03 05:59:46 <CIA-17> 03koen 07org.oe.dev * rb98af8fe... 10/ (1 site/common-glibc): common-glibc: add mono and guile stuff
Sep 03 06:20:11 <steliosk> good morning all
Sep 03 06:22:36 <koen> good morning all
Sep 03 06:39:09 <steliosk> koen : hi
Sep 03 06:40:10 <rwhitby> hey koen 
Sep 03 06:44:09 <rwhitby> koen: there seems to be a problem in task-base where spectrum-fw is being pulled in in the openmoko distro build, even though fic-gta01 does not include pcmcia in MACHINE_FEATURES - any idea why that could be the case?
Sep 03 06:47:01 <koen> tried bitbake -g ?
Sep 03 06:47:10 <rwhitby> yeah, it said task-base
Sep 03 06:47:32 <rwhitby> but from what I can tell, task-base is correctly looking at COMBINED_FEATURES
Sep 03 06:48:30 <RP> rwhitby: I think we build the package with spectrum-fw in it even if we don't use the resulting package so bitbake is doing the right thing and task-base could be better designed :/
Sep 03 06:50:23 <rwhitby> ah, I see.
Sep 03 06:50:34 <rwhitby> ok, how do we redesign it then?
Sep 03 06:51:22 <rwhitby> cause there will doubtless be a case in the future where something obscure that no-one uses in task-base doesn't build, and takes out all users of task-base until it's fied.
Sep 03 06:51:25 <rwhitby> fixed.
Sep 03 06:52:10 <koen> the idea is that nothing in task-base is obscure
Sep 03 06:53:55 <rwhitby> yes, but that doesn't excuse stuff being built which is never going to be used by the machine/distro which is calling task-base
Sep 03 06:54:29 <rwhitby> RP: do you know how it should be redesigned?  is it just some work that someone needs to do, or is the redesign the first step that someone needs to work out?
Sep 03 06:55:21 <RP> rwhitby: Someone would need to work it out. The options are to split it into several task files, or to adjust PACKAGES so unused ones are removed
Sep 03 06:55:34 <RP> I'm not keen on either particularly :/
Sep 03 06:55:46 <rwhitby> what's wrong with the second option?
Sep 03 06:56:02 <rwhitby> (it seems to make logical sense)
Sep 03 06:56:05 <RP> I'm not sure how it would be done neatly...
Sep 03 06:56:14 <RP> It makes more sense than the first though
Sep 03 06:57:52 <koen> anonymous function?
Sep 03 06:59:59 <CIA-17> 03pH5 07org.oe.dev * r4009edff... 10/ (1 packages/python/python-pygobject_2.12.3.bb): 
Sep 03 06:59:59 <CIA-17> python-pygobject-2.12.3: fix packaging
Sep 03 06:59:59 <CIA-17> - move pc into -dev package, stops python-pygobject from depending on libglib-2.0-dev
Sep 03 06:59:59 <CIA-17> - package xsl files
Sep 03 07:00:06 <CIA-17> 03pH5 07org.oe.dev * rd0071324... 10/ (1 packages/python/python-pygtk_2.10.4.bb): python-pygtk-2.10.4: add runtime dependencies on python-pygobject and -pycairo
Sep 03 07:02:58 <koen> RP: what do you think about using debtags to tag the arm ISA it builds for?
Sep 03 07:03:43 <RP> koen: What were you thinking of calling the tag and what would we use it for?
Sep 03 07:03:59 <koen> 'armvt53' 'armv4t', etc
Sep 03 07:04:03 <koen> ehm
Sep 03 07:04:07 <koen> armv5te
Sep 03 07:04:29 <RP> no, they're the values you'd use...
Sep 03 07:04:30 <koen> that way we can find out if a given .deb will work
Sep 03 07:04:43 <RP> You mean instead of the current "arm" value?
Sep 03 07:04:51 <koen> yes
Sep 03 07:05:04 <RP> Won't work, the architecture list is hardcoded into dpkg
Sep 03 07:07:22 <koen> I know that, that's why I wanted to use tags
Sep 03 07:16:15 <RP> koen: I've jsut read up on debtags, I don't think it buys us anything
Sep 03 07:17:01 <koen> RP: I just want a way to see what a given .deb is :)
Sep 03 07:17:16 <RP> I'd just add an extra field
Sep 03 07:32:09 <koobla> good morning all!
Sep 03 07:36:41 <hrw> morning
Sep 03 07:39:07 <hrw> binutils 2.18 released
Sep 03 07:40:28 <koen|away> any cool changes?
Sep 03 07:40:29 <hrw> and debian use gcc 4.2.1 now
Sep 03 07:40:40 <hrw> koen|away: no idea - just got in debian updates
Sep 03 07:41:29 * koen|away wishes uclibc would work with gcc 4.2.1 in OE
Sep 03 07:43:24 <koen|away> bleh
Sep 03 07:43:28 <koen|away> uni started today
Sep 03 07:52:11 <XorA> morning
Sep 03 07:52:30 <tiny> Hello! I hope this is the right channel to ask this sort of question. I'm interested in building a fairly recent gcc cross-toolchain for MS Windows boxes. It'll be for PowerPC system.
Sep 03 07:52:33 <tiny> Now ...
Sep 03 07:53:09 <XorA> tiny: you would probably have to invest quite some time making bitbake/OE run in cygwin
Sep 03 07:53:14 <tiny> I've seen stuff from montavista and even windriver is shipping some toolchains and tools with it.
Sep 03 07:53:29 <tiny> I've built stuff on cygwin before
Sep 03 07:53:52 <tiny> It was a pain but it worked ... I even made it work with eclipse.
Sep 03 07:53:55 <XorA> tiny: OE is a bit more complex than "stuff" and its been a long time since someone tried it in cygwin
Sep 03 07:54:08 <XorA> tiny: but if you did it cleanly we would love the patches
Sep 03 07:54:20 <tiny> Well it wasn't OE. But it was a working toolchain. C, C++
Sep 03 07:54:56 <tiny> Ok so my question is really this.
Sep 03 07:55:09 <tiny> Is there some other way then building it with cygwin?
Sep 03 07:55:26 <RP> hrw: We should get poky using the new binutils as it will hopefully remove the annoying warnings...
Sep 03 07:55:26 <tiny> I saw gcc is being made for Windows also.
Sep 03 07:55:57 <XorA> tiny: some people run OE on a vmware or colinux VM under windows
Sep 03 07:56:05 <XorA> tiny: when they are stuck in corporate hell
Sep 03 07:56:33 <tiny> Yes, I'm aware of that. It's what I'm trying to get out off. I have two colleagues that are stuck that way :)
Sep 03 07:56:57 <hrw> RP: want me to check it?
Sep 03 07:57:38 <tiny> XorA: So the "cygwin way" is still the sanest way to go?
Sep 03 07:57:55 <XorA> tiny: not sure about sane, but I think without using a VM is the only way we can offer
Sep 03 07:58:04 <XorA> tiny: but no-one has tried this for years
Sep 03 08:00:36 <tiny> There are companies that offer prebuilt cross-toolchains. I'm just curios how they build them. :)
Sep 03 08:00:44 <tiny> Such as: http://www.ronetix.at/software.html
Sep 03 08:01:41 <XorA> tiny: probably by hand, or a few custom scripts, building a toolchain ist too difficult
Sep 03 08:01:50 <XorA> s/ist/isnt/
Sep 03 08:01:57 <hrw> debian has binutils 2.18 - but upstream did not released tarballs yet ;D
Sep 03 08:01:57 <XorA> damn N key is sticky
Sep 03 08:02:16 <XorA> hrw: I hope debian has a tarball on its servers :-)
Sep 03 08:02:21 <tiny> XorA: it's a breeze on linux box but PITA on MS crap.
Sep 03 08:02:34 <hrw> no - we fetch from kernel.org instead of gnu.org
Sep 03 08:02:49 <XorA> tiny: well if you want eternal kudos then make OE work on windows :-D
Sep 03 08:03:00 <tiny> heh
Sep 03 08:07:21 <likewise> gm
Sep 03 08:09:24 <hrw> our binutils patches suxx
Sep 03 08:12:45 <hrw> lack of "-p" diff info, patches to 2.16.something still present, no info about status or source of patches
Sep 03 08:15:08 <RP> hrw: poky hasn't updated to use the kernel mirrors so its fetching when I added a recipe there :)
Sep 03 08:15:49 <hrw> ;D
Sep 03 08:24:33 <hrw> NOTE: package binutils-cross-2.18-r0: task do_patch: completed
Sep 03 08:36:41 <XorA> run-parts: unrecognized option `--reverse'
Sep 03 08:36:41 <XorA> BusyBox v1.2.1 (2007.08.13-15:42+0000) multi-call binary
Sep 03 08:36:41 <XorA> Usage: run-parts [-t] [-a ARG] [-u MASK] DIRECTORY
Sep 03 08:36:51 <XorA> I think hal needs to RDEPEND on a real run-parts
Sep 03 08:56:49 <RP> I've noticed a problem with the "export IMAGE_BASENAME ?=" in image,bbclass btw. We might have to revert that to a straight = until someone fixes bitbake :-(
Sep 03 09:06:16 <oxo> hmm
Sep 03 09:06:46 <oxo> anybody knows why package-index fails with `rootfs_ipk_do_indexes: command not found' since a mtn pull?
Sep 03 09:14:25 <likewise> hrw:/exit
Sep 03 09:14:28 <likewise> whoops
Sep 03 09:24:38 <RP> oxo: It needs fixing, my fault
Sep 03 09:24:55 <koen|away> XorA: dbus needs it as well (runparts), see bugtracker
Sep 03 09:25:07 <XorA> koen|away: cool
Sep 03 09:25:20 <XorA> and for somereason my keymap is not loaded
Sep 03 09:25:27 <XorA> which is odd as startup script is there
Sep 03 09:26:51 <oxo> RP: k, tnx
Sep 03 09:29:18 <koen|away> XorA: http://bugs.openembedded.org/show_bug.cgi?id=2753
Sep 03 09:34:44 <RP> oxo: fix pushed
Sep 03 09:35:31 <RP> XorA: FWIW, /dev entries were being broken by the makedevs changes, I don't know if that was related
Sep 03 09:35:37 <RP> I've tried to patch up makedevs
Sep 03 09:36:11 <XorA> RP: Ill have to catch the early debug message and see
Sep 03 09:45:47 <CIA-17> 03rpurdie 07org.oe.dev * rc1014f98... 10/ (1 packages/meta/package-index.bb): package-index.bb: Catch up with package/rootfs changes
Sep 03 09:45:52 <CIA-17> 03rwhitby 07org.oe.dev * r0bc3c321... 10/ (1 packages/tasks/task-openmoko-feed.bb): openmoko-feed: Added heaps of packages requested by community members.
Sep 03 09:49:33 <florian> good morning
Sep 03 09:53:41 <zecke> moin
Sep 03 09:53:49 <zecke> mallum: hey!
Sep 03 09:55:03 <RP> zecke: You could talk to mallum about clutter (he'll know who/where to point your questions) :)
Sep 03 09:55:16 <RP> zecke: morning btw :)
Sep 03 09:55:20 <zecke> mallum: two things. Do you have ~350mb webspace for a git tree
Sep 03 09:55:46 <zecke> mallum: and feel like giving me food and shelter for a day or two to talk about WebKit and show you where to add clutter?
Sep 03 09:56:01 * zecke is almost on vacation (hacking vacation though...)
Sep 03 09:56:25 <zecke> RP: morning :)
Sep 03 09:56:49 <mallum> zecke: ??
Sep 03 09:56:58 <oxo> RP: it works, thanks
Sep 03 09:57:27 <koen|away> RP: fyi, the OE autobuilder is offline till tomorrow to have a fresh start with bitbake 1.8.8 and the bbclass updates 
Sep 03 09:58:12 <mallum> zecke: you want to come visit ?
Sep 03 10:00:03 <RP> koen|away: ok, sounds good
Sep 03 10:01:23 <hrw> koen|away: you use that script only for autobuilder?
Sep 03 10:08:12 <zecke> mallum: Well, first I have some stubs for WebKit/clutter which just compiles and links and I want you to fill in the blanks
Sep 03 10:08:37 <mallum> zecke: woo :)
Sep 03 10:09:04 <zecke> mallum: if it helps to fill in the blanks I can come and visit you guys for a day or two
Sep 03 10:09:23 <mallum> zecke: were you planning on coming to UK anyway ?
Sep 03 10:09:45 <mallum> zecke: and what sort o date were you thinking ?
Sep 03 10:09:52 <zecke> mallum: and finally the git tree with the clutter changes is ~300mb and I would like to put that somewhere. So if you know a place to put it that would be appreciated
Sep 03 10:10:28 <zecke> mallum: I'm almost on vacation and want to go north denmark, sweden and probably on my return visit the UK (this is september)
Sep 03 10:10:44 <mallum> zecke: okeys, late sept ?
Sep 03 10:10:51 <zecke> mallum: yes
Sep 03 10:20:05 <XorA> hey mickey|train 
Sep 03 10:20:34 <mickey|train> hi XorA 
Sep 03 10:21:16 <hrw> mickey|train: moin
Sep 03 10:21:24 <mickey|train> hey
Sep 03 10:25:09 <RP> mickey|train: That fifo problem was makedevs. The fifo code just simple wasn't implemented
Sep 03 10:25:36 <RP> We didn't use to hit the problem as it didn't create the file at all
Sep 03 10:25:45 <mickey|train> RP: ok, good to hear you've found it
Sep 03 10:26:03 <mickey|train> aah heh
Sep 03 10:26:19 <koen|away> hey mickey|train 
Sep 03 10:26:26 <mickey|train> salve koen
Sep 03 10:57:01 <rwhitby> is there a virtual/libsdl-native ?
Sep 03 10:57:16 <rwhitby> (scummvm requires libsdl-native as a new DEPENDS)
Sep 03 10:59:09 <rwhitby> or do I just make it depend on libsdl-native ?
Sep 03 10:59:23 <rwhitby> (scummvm requires the sdl-config which is staged to configure)
Sep 03 10:59:43 <hrw> why it needs native one?
Sep 03 11:01:15 <rwhitby> it's looking in tmp/staging/i686-linux/bin for sdl-config
Sep 03 11:01:39 <rwhitby>  --with-sdl-prefix=${STAGING_BINDIR_NATIVE}/.. 
Sep 03 11:01:46 <rwhitby> maybe scummvm is broken
Sep 03 11:02:30 <hrw> give STAGING_BINDIR_CROSS rather
Sep 03 11:12:57 <cdbot2> * * OE Bug 2914 has been created by hma(AT)syd.odn.ne.jp
Sep 03 11:12:59 <cdbot2> * * gcc-cross-4.1. 2-r6 fails to compile  because of internal compiler error
Sep 03 11:13:01 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=2914
Sep 03 11:16:16 <rwhitby> hrw: will do, thx
Sep 03 11:16:50 <interfaith> rwhitby: angstrom-minimal root password ? hint ?
Sep 03 11:17:24 <hrw> interfaith: none
Sep 03 11:17:45 <interfaith> none does not work
Sep 03 11:17:59 <interfaith> shall i hack work/rootfs/etc/passwd and recompile ?
Sep 03 11:18:14 <hrw> none as empty as no pass
Sep 03 11:18:25 <interfaith> right..that fails
Sep 03 11:18:30 <rwhitby> interfaith: are you running angstrom or slugos ?
Sep 03 11:18:48 <interfaith> slugos distro and angstrom-minimal image
Sep 03 11:19:05 <rwhitby> that's not a supported combination
Sep 03 11:19:11 <interfaith> oh 
Sep 03 11:19:26 <rwhitby> try 'opeNSLUg' as the root password, since you are using the slugos distro
Sep 03 11:19:33 <interfaith> there is a gstreamer compile error for the task-base
Sep 03 11:19:40 <interfaith> hmm
Sep 03 11:20:06 <rwhitby> why are you using slugos when you're not targetting an NSLU2 ?
Sep 03 11:20:16 <rwhitby> why are you not using Angstrom directly?
Sep 03 11:20:17 <interfaith> yes that worked ! thank
Sep 03 11:20:48 <interfaith> oh.. no need for any X11 etc ?
Sep 03 11:21:07 <rwhitby> what's that got to do with using the Angstrom distribution?
Sep 03 11:21:08 <interfaith> just trying to get ethernet to work now
Sep 03 11:21:36 <rwhitby> use Angstrom.  then you can get support in #oe or #angstrom and not confuse people by using SlugOS on a non-NSLU2.
Sep 03 11:21:40 <interfaith> just fishing for an image that will work
Sep 03 11:21:59 <interfaith> use angstrom distro ?
Sep 03 11:22:12 <rwhitby> yes
Sep 03 11:22:31 <interfaith> ok, they all seem to come up without any network
Sep 03 11:22:34 <rwhitby> what MACHINE are yo uusing?
Sep 03 11:22:47 <interfaith> the ixp425 ixdpg425
Sep 03 11:22:55 <interfaith> with more RAM and more FLASH
Sep 03 11:23:06 <rwhitby> what is the value of MACHINE
Sep 03 11:23:08 <mickey|train> RP: how would you add scaling to your --root-ppm patch?
Sep 03 11:23:15 <mickey|train> (kdrive)
Sep 03 11:23:19 <interfaith> 604
Sep 03 11:23:26 <rwhitby> I give up
Sep 03 11:23:29 <interfaith> oh
Sep 03 11:23:42 <interfaith> ixp4xxbe
Sep 03 11:23:44 <rwhitby> interfaith: you set MACHINE and DISTRO to build OE.  What are the values of those variables in your setup.
Sep 03 11:23:48 <rwhitby> right.
Sep 03 11:23:58 <interfaith> 1 sec
Sep 03 11:24:08 <interfaith> slugos and ixp4xxbe
Sep 03 11:24:09 <rwhitby> build DISTRO = "angstrom-2007.1"
Sep 03 11:24:10 <interfaith> sorry
Sep 03 11:24:39 <interfaith> yes that may work
Sep 03 11:24:53 <rwhitby> and then use #ansgstrom for support, cause angstrom supports ixp4xxbe
Sep 03 11:25:01 <interfaith> i see
Sep 03 11:25:07 <interfaith> ok i will rebuild now
Sep 03 11:25:08 <rwhitby> #angstrom that is
Sep 03 11:25:31 <interfaith> so use angstrom-2007.1 distro and ixp4xxbe for machine
Sep 03 11:25:49 <rwhitby> and make sure you've read both the bitbake manual and the OE manual before asking questions there.
Sep 03 11:26:10 <rwhitby> yes, those values are correct.
Sep 03 11:26:17 <interfaith> i see, well redboot comes up with the network fine, thx
Sep 03 11:26:56 <interfaith> i have read the manuals, however digesting is another matter
Sep 03 11:27:25 <rwhitby> the good thing is there are hundreds of examples ...
Sep 03 11:27:32 <interfaith> alright.. i'll retreat.. yes
Sep 03 11:28:07 <rwhitby> not trying to scare you off - just making sure you're prepared before you enter #ansgtrom :-)
Sep 03 11:28:14 <interfaith> fine
Sep 03 11:28:22 * rwhitby can't type #angstrom for nuts
Sep 03 11:28:29 <interfaith> ha ha
Sep 03 11:28:47 <interfaith> is there a website for angstrom ?
Sep 03 11:33:04 <rwhitby> google found it on the second hit for me ...
Sep 03 11:33:40 <CIA-17> 03rwhitby 07org.oe.dev * re7c327f7... 10/ (1 packages/scummvm/scummvm.inc): scummvm: Fixed the staging dir location. Thx hrw for the tip.
Sep 03 11:33:46 <CIA-17> 03rwhitby 07org.oe.dev * r4e26b0f4... 10/ (1 packages/tasks/task-openmoko-feed.bb): openmoko-feed: Added scummvm.
Sep 03 11:48:40 <Jin|away> does uboot git have any mirror or something
Sep 03 11:48:41 <Jin|away> ?
Sep 03 11:49:07 <Jin^eLD> I'm trying to build Croftons DaVinci image for a second week now :) and it always fails because the uboot git repo is down
Sep 03 11:51:44 <interfaith> uboot from denx.de ?
Sep 03 11:51:49 <Jin^eLD> yes
Sep 03 11:52:15 <interfaith> ixp4xx u-boot git was ok
Sep 03 11:52:24 <interfaith> what fork ?
Sep 03 11:52:42 <Jin^eLD> pff.. no idea.. Crofton would know I guess; its anstrom for TI DaVinci
Sep 03 11:53:11 <interfaith> well the website is tricky , to get the correct fork
Sep 03 11:53:38 <interfaith> there is a uboot arm ixp4xx fork
Sep 03 11:53:53 <Jin^eLD> aha.. I do not know what the davinci is using
Sep 03 11:54:11 <zecke> koen|away: what is the ETA on getting our site fixed?
Sep 03 11:54:16 <interfaith> what processor ?
Sep 03 11:54:20 <zecke> koen|away: can one some how help?
Sep 03 11:55:27 <Jin^eLD> interfaith: arm
Sep 03 11:55:39 <Jin^eLD> just has PREFERRED_VERSION_u-boot = "git"
Sep 03 11:55:45 <Jin^eLD> mhm crap, have to go to a meeting now, brb
Sep 03 11:57:26 <interfaith> http://www.denx.de/cgi-bin/gitweb.cgi
Sep 03 11:57:50 <interfaith> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=forks
Sep 03 12:20:50 <interfaith> rwhitby: task-base builds ok others fail
Sep 03 12:21:38 <interfaith> rwhitby: must be late on your side
Sep 03 12:21:58 <hrw> interfaith: why you do not show failed log?
Sep 03 12:22:21 <interfaith> there is the console log messages
Sep 03 12:22:38 <interfaith> mtd-utils-native fails
Sep 03 12:23:04 <interfaith> bitbake task-base is ok bitbake bootstrap-image fails
Sep 03 12:23:12 <interfaith> perhap clean and rebuild ?
Sep 03 12:23:26 <hrw> interfaith: 'mtd-utils-native fails' is useless
Sep 03 12:24:23 <interfaith> mtd-utils-native_1.0.0+git.bb do_compile failed
Sep 03 12:25:35 <hrw> ah... that
Sep 03 12:25:46 <hrw> upgrade your gcc as gcc 1.3 is not enough
Sep 03 12:27:22 <interfaith> gcc cross version is 4.x.. i thought
Sep 03 12:28:00 <interfaith> upgrade native gcc ?
Sep 03 12:28:36 <hrw> no - show the fscking log
Sep 03 12:28:43 <hrw> ~pastebin
Sep 03 12:28:44 <ibot> it has been said that pastebin is a place to paste your stuff without flooding the channel - try  http://pastebin.ca, or http://channels.debian.net/paste, or http://rafb.net/paste/, or http://pastebin.com is usually painfully too slow and unresponsive to use, use one of the other pastebin sites, or dpaste.com is a very nice pastebin as well
Sep 03 12:28:53 <interfaith> ok
Sep 03 12:29:50 <koen|away> zecke: I mailed oe-devel about it
Sep 03 12:30:24 <koen|away> zecke: I fixed all sql errors and am now at the limit of website knowledge, so someone else needs to fix it (and viewmtn too)
Sep 03 12:31:23 <zecke> still the mail from the 25th?
Sep 03 12:31:28 <zecke> 24th even
Sep 03 12:31:28 <XorA> koen|away: try emptying the cache table in drupal db
Sep 03 12:31:46 <XorA> koen|away: I have found sometime pute crap gets cached even when caching is disabled
Sep 03 12:33:17 <interfaith> paste bin is www.pastebin.ca/679855
Sep 03 12:34:51 <interfaith> hrw: pastebin is ready pastebin.ca/679855
Sep 03 12:35:11 <koen|away> XorA: how can I do that?
Sep 03 12:35:31 <XorA> koen|away: phpPgAdmin just delete all rows in all tables called cache_*
Sep 03 12:35:46 <hrw> interfaith: update metadata
Sep 03 12:36:03 <interfaith> bitbake something ?
Sep 03 12:36:07 <XorA> koen|away: but I really wish I could remeber the exact trick I did to fix the reversedness
Sep 03 12:36:19 <XorA> koen|away: as my website was exactly the same for half an hour or so
Sep 03 12:36:21 <hrw> interfaith: update metadata
Sep 03 12:36:28 <hrw> interfaith: mtn pull;mtn update
Sep 03 12:36:32 <interfaith> ok
Sep 03 12:36:34 <interfaith> :)
Sep 03 12:36:45 <interfaith> clueless here
Sep 03 12:37:57 <hrw> interfaith: updating OE once per week is not good - atleast once per day is better
Sep 03 12:38:04 <interfaith> i see
Sep 03 12:38:16 <interfaith> it has been a few days
Sep 03 12:38:28 <koen|away> drupal-oe=> delete from cache;
Sep 03 12:38:28 <koen|away> DELETE 37
Sep 03 12:38:29 <koen|away> drupal-oe=> \q
Sep 03 12:50:10 <interfaith> hrw: looks like a major rebuild now getting gcc etc again
Sep 03 13:12:18 <steliosk> hrw : Does it make sense to "tune" i585-generic and i686-generic ?
Sep 03 13:13:09 <CIA-17> 03rwhitby 07org.oe.dev * r0e85448c... 10/ (1 packages/tasks/task-openmoko-feed.bb): openmoko-feed: Added ipkg-link
Sep 03 13:14:48 <koen|away> rwhitby: ipkg-link is considered harmfull
Sep 03 13:15:01 <koen|away> it does not work as users expect
Sep 03 13:15:26 <hrw> steliosk: they are generic so maybe not
Sep 03 13:15:48 <hrw> steliosk: and intel naming is unusable mess
Sep 03 13:16:42 <hrw> steliosk: i586 used to be Pentium1 compatible (no mmx/sse/3dnow etc) but it is no longer true
Sep 03 13:16:44 <steliosk> hrw : i think the code we get although we mention i585 and i686 is actually i484
Sep 03 13:17:01 <steliosk> s/i484/i486
Sep 03 13:17:08 <koobla> all, I just composed a small bb file for the pxaregs utility including the gumstix patches (need it for my connex board) - should I add it to the bugtracker?
Sep 03 13:17:21 <hrw> koobla: sure
Sep 03 13:17:28 <koobla> ok :)
Sep 03 13:17:43 <hrw> I will add it
Sep 03 13:17:55 <koobla> just a mom
Sep 03 13:18:07 <hrw> steliosk: but how to tune them?
Sep 03 13:18:27 <hrw> steliosk: i586 could be -mcpu=pentium and i686 == -mcpu=pentiumpro?
Sep 03 13:18:42 <steliosk> hrw : Follow kernel's example ?
Sep 03 13:19:04 <hrw> steliosk: in kernel you choose exact cpu not arch
Sep 03 13:19:49 <steliosk> hrw : I know, we could do the same in OE, but we will end up with a gazilion machine files
Sep 03 13:20:05 <hrw> yep ;(
Sep 03 13:20:40 <sakoman> good morning!
Sep 03 13:21:21 <sakoman> koen|away:  I tried your new angstrom-feed-configs recipe
Sep 03 13:21:28 <steliosk> hrw : How about using some "python magic" to get the correct mcpu settings ?
Sep 03 13:21:52 <sakoman> koen|away:  Got it to half work :-)
Sep 03 13:22:13 <hrw> i sakoman 
Sep 03 13:22:37 <hrw> steliosk: and which PACKAGE_ARCH then?
Sep 03 13:22:37 <koobla> pxaregs - bug #2915
Sep 03 13:22:38 <sakoman> hi hrw!
Sep 03 13:23:06 <hrw> steliosk: if I want to build for k6-2 then I want -mcpu=k6-2 so PACKAGE_ARCH=k62?
Sep 03 13:23:32 <steliosk> hrw : hmmm
Sep 03 13:24:56 <sakoman> koen|away:  ANGSTROM_URI override was successful, FEED_BASEPATH wasn't
Sep 03 13:25:42 <steliosk> hrw : we need at least to set a "common" minimum standard even for the "generic" architectures. They way they are now, you don't get i585 or i686 code you get the same like x86
Sep 03 13:25:46 <sakoman> koen|away:  used the following lines in my image recipe:
Sep 03 13:25:49 <sakoman> ANGSTROM_URI = "http://www.sakoman.net"
Sep 03 13:25:49 <sakoman> FEED_BASEPATH = "feeds/s100/" 
Sep 03 13:26:39 <hrw> steliosk: so pentium for i586 and pentiumpro for i686 I suggest
Sep 03 13:26:49 <sakoman> basepath stayed set to "unstable/feed/"
Sep 03 13:26:57 <cdbot2> * * OE Bug 2915 has been created by simon.vogl(AT)researchstudio.at
Sep 03 13:26:59 <cdbot2> * * pxaregs utility for gumstix
Sep 03 13:27:01 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=2915
Sep 03 13:28:13 <steliosk> hrw : ok with me. at least we will not get similar code as x86
Sep 03 13:28:29 <steliosk> hrw : should we post to the list asking for input ?
Sep 03 13:29:55 <hrw> steliosk: I think that we can push it and start discussion about it then
Sep 03 13:34:48 <hrw> koobla: pushing pxaregs
Sep 03 13:35:05 <hrw> koobla: thx for recipe - I had one for it months ago but forgot where ;D
Sep 03 13:35:41 <koen|away> sakoman: will look into later, thanks
Sep 03 13:37:57 <cdbot2> * * OE Bug 2915 has been RESOLVED (FIXED) by <hrw>
Sep 03 13:37:59 <cdbot2> * *  pxaregs utility for gumstix
Sep 03 13:38:01 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=2915
Sep 03 13:38:24 <hrw> koobla: for future do not add 'for gumstix' for such universal apps ;)
Sep 03 13:41:00 <koobla> ok :)
Sep 03 13:42:03 <koobla> only referred to the patches from the gumstix repo
Sep 03 13:44:10 <hrw> koobla: did you sent those patches upstream?
Sep 03 13:47:05 <CIA-17> 03xora 07org.oe.dev * rcee1094c... 10/ (1 packages/xournal/xournal_0.4.bb): xournal_0.4.bb : version upgrade
Sep 03 13:47:10 <steliosk> btw who is the designated OpenMoko dev ?
Sep 03 13:47:11 <CIA-17> 03simon.vogl 07org.oe.dev * rc76448c3... 10/ (9 files in 4 dirs): pxaregs: added 1.14 - close #2915
Sep 03 13:50:11 <steliosk> koen : any plans to get the wiki to its "last know good" state ?
Sep 03 13:50:18 <koobla> hrw: don't have write access
Sep 03 13:53:29 <hrw> koobla: your mail program is borken? by upstream I mean author of pxaregs
Sep 03 13:54:53 <yakov_> hi
Sep 03 13:59:18 <interfaith> hrw: angstrom comes up ok now, however no network devices
Sep 03 13:59:52 <interfaith> time to hack some network startup , as redboot is fine on NPE-B
Sep 03 14:00:15 <koen|away> steliosk: I sent a mail to oe-devel asking for help last week
Sep 03 14:00:23 * koen|away wishes people would read their mail
Sep 03 14:00:27 <CIA-17> 03freyther 07org.oe.dev * r862b21d8... 10/ (6 files in 3 dirs): 
Sep 03 14:00:27 <CIA-17> classes/{qmake*,qt4x11}.bbclass: Add a qmake2.bbclass to use qmake version two
Sep 03 14:00:27 <CIA-17>  Add a qmake2.bbclass which currently takes over the role of qt4x11.bbclass
Sep 03 14:00:27 <CIA-17>  with setting the QTDIR, MOC, UIC properly. qmake2 and qmake now share
Sep 03 14:00:27 <CIA-17>  qmake-base.bbclass this is why some var assignments and functions have
Sep 03 14:00:27 <CIA-17>  been moved around.
Sep 03 14:00:30 <CIA-17>  Make webkit-gtk use qmake2 to eliminate the Qt3 and Qt4/X11 dependency.
Sep 03 14:01:05 <CM> zecke: Nice! :D
Sep 03 14:01:48 <steliosk> koen|away : Haven't seen any significant traffic on that subject and that's why i am asking
Sep 03 14:07:08 <koen|away> hrw: and progress on using non-broken prism firmware?
Sep 03 14:07:37 <XorA> koen|away: Ive just made a .bb for that
Sep 03 14:08:36 <hrw> koen|away: feel free to adapt to other revision?
Sep 03 14:08:51 <XorA> hrw: already done, just need to test
Sep 03 14:09:32 <hrw> great
Sep 03 14:13:22 <XorA> <6>wifi0: NIC: id=0x801d v1.0.0
Sep 03 14:13:23 <XorA> <6>wifi0: PRI: id=0x15 v1.1.2
Sep 03 14:13:23 <XorA> <6>wifi0: STA: id=0x1f v1.7.4
Sep 03 14:13:57 <cdbot2> * * OE Bug 2916 has been created by compovod(AT)gmail.com
Sep 03 14:13:59 <cdbot2> * * gnome-desktop_2.18.3 fails do_configure
Sep 03 14:14:01 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=2916
Sep 03 14:23:55 <XorA> koen|away: pushed
Sep 03 14:26:57 <cdbot2> * * OE Bug 2762 has been RESOLVED (FIXED) by dp(AT)xora.org.uk
Sep 03 14:26:59 <cdbot2> * *  prism2-firmware 1.8.4 does not work on DCF-660W
Sep 03 14:27:01 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=2762
Sep 03 14:34:46 <koen|away> XorA: thank
Sep 03 14:47:42 <mickey|ICE79> florian: are you available for a call end of this week? want to talk w/ you about to OHM or not ;) (device manager stuff)
Sep 03 15:00:56 <CIA-17> 03tmbinc 07org.oe.dreambox * re1d8591a... 10/ (1 packages/enigma2/enigma2.bb): enigma2: switch to release 2.3
Sep 03 15:01:01 <CIA-17> 03tmbinc 07org.oe.dreambox * r59af2581... 10/ (1 packages/dreambox/dreambox-dvb-modules.bb): dreambox-dvb-modules: use 20070826 for dm7025
Sep 03 15:01:04 <koen> mickey|ICE79: the best thing to do medium term is to make neod more generic (shouldn't be hard with kernel 2.6) and show it as a usecase to the ohm dudes
Sep 03 15:01:09 <CIA-17> 03xora 07org.oe.dev * ra5a7ee98... 10/ (3 files in 3 dirs): 
Sep 03 15:01:09 <CIA-17> misc-binary-only/prism-firmware.bb : use non broken prism firmware. This
Sep 03 15:01:09 <CIA-17> should ease the connection problems people reported with 1.8.4 and
Sep 03 15:01:09 <CIA-17> improve kismetting
Sep 03 15:01:16 <CIA-17> 03hrw 07org.oe.dev * r0b5587ed... 10/ (11 files in 3 dirs): binutils: added 2.18 from Poky (normal, cross, sdk)
Sep 03 15:02:05 * hrw removed nearly 5000 files from DL_DIR
Sep 03 15:02:11 <hrw> 3.6GB
Sep 03 15:02:39 <mickey|ICE79> koen: yeah, might be the necessary thing to do. but once i do what i like it to do i risk reinventing OHM completely
Sep 03 15:03:07 <mickey|ICE79> e.g. input/output/plugins
Sep 03 15:03:07 <mickey|ICE79> i need all these concepts
Sep 03 15:03:17 <koen> + hal integration
Sep 03 15:03:41 <mickey|ICE79> and naturally i want to use dbus as well
Sep 03 15:03:50 <koen> if openmoko, gpe and poky all use neod, maintenance isn't the problem
Sep 03 15:04:39 <hrw> so few parts of openmoko will use dbus and few do not..
Sep 03 15:05:06 <koen> anything harald touches will be overengineered and crappy
Sep 03 15:05:19 <koen> but it won't use dbus!
Sep 03 15:06:43 <hrw> or glib!
Sep 03 15:06:54 <hrw> glibc is enough for anything
Sep 03 15:07:16 <hrw> you can even dial with glibc
Sep 03 15:07:28 <koen> :)
Sep 03 15:08:05 <koen> considering that  lowlevel stuff like HAL and bluez now use dbus, I can't see why people make a big deal about it being a dependency
Sep 03 15:08:22 <koen> it's not like there will be new phones that use gsmd without bluetooth
Sep 03 15:08:42 <mickey|ICE79> true
Sep 03 15:08:42 <mickey|ICE79> hrw: most will do
Sep 03 15:08:52 <mickey|ICE79> even gsm, if that's what you are implicitly complaining about :D
Sep 03 15:09:00 <mickey|ICE79> well, give him a break
Sep 03 15:09:02 <mickey|ICE79> let him do the low level stuff
Sep 03 15:09:06 <mickey|ICE79> the high level stuff will come
Sep 03 15:09:08 <mickey|ICE79> there's no need to convince him to do that
Sep 03 15:09:12 <mickey|ICE79> but there's no point in adding a dbus interface when gsmd-nodbus is so flakey
Sep 03 15:09:14 <mickey|ICE79> one step at a time 
Sep 03 15:09:18 <mickey|ICE79> well, bluez's usage of dbus still is a source for lots of anger
Sep 03 15:09:20 <mickey|ICE79> i don't care at all. i made my peace with dbus :D
Sep 03 15:09:39 <koen> the new xorg will use dbus for hotplug and randr signalling :)
Sep 03 15:11:09 <koen> mickey|ICE79: the point was that things like dbus-activation solve a lot of the flakyness :) 
Sep 03 15:11:34 <robtaylor> koen: and hal =)
Sep 03 15:11:44 <mickey|ICE79> joking?
Sep 03 15:11:44 <mickey|ICE79> or really?
Sep 03 15:11:46 <mickey|ICE79> i wouldn't be surprised
Sep 03 15:11:57 <mickey|ICE79> i'm afraid the major question -- albeit a very controversial one -- is whether using most of these "desktop-emerged" technologies is a step in the right direction. i still have a lot of doubts myself.
Sep 03 15:12:00 <koen> mickey|ICE79: X will really use dbus
Sep 03 15:12:10 <robtaylor> mickey|ICE79: seriously
Sep 03 15:12:40 <robtaylor> mickey|ICE79: there's nothing inherenct in these 'desktot technologies' that makes them inapplicable to embedded
Sep 03 15:13:11 <robtaylor> mickey|ICE79: its just a matter of embedded-focussed guys (like you and me) spending time with them to make them right ;)
Sep 03 15:13:54 <XorA> and just think, when everything is dbus capable, the Neo doesnt need to run as root anymore
Sep 03 15:15:03 <koen> XorA: I was saving the root discussion for when the openmoko maintainer reveals himself :)
Sep 03 15:15:15 <koen> or herself
Sep 03 15:15:16 <robtaylor> XorA: heh, so true. With PolicyKit everything canbe securely backended
Sep 03 15:15:54 <robtaylor> XorA: seen hugsies PackageKit too? it'd be cool to have an oe feed backedn
Sep 03 15:16:10 <XorA> robtaylor: I am behind the newest tech
Sep 03 15:16:19 <XorA> robtaylor: some hols coming up so I can catch up
Sep 03 15:16:20 <hrw> rwhitby: to not build spectrum-fw when you build for fic-gta01 (or other !pcmcia machine) we need to change task-base in a way similiar to the one in Poky
Sep 03 15:16:29 <koen> robtaylor: I've been mentioning 'packagekit' and 'me want' a lot lately here in oe :)
Sep 03 15:16:35 <hrw> rwhitby: where some tasks are built only if machine supports it
Sep 03 15:16:40 <robtaylor> koen: nice :)
Sep 03 15:16:49 <robtaylor> koen: you should practice some programming ;)
Sep 03 15:16:50 <XorA> koen: yah lazy student get it checked in then :-D
Sep 03 15:18:31 <robtaylor> mickey|ICE79: btw, if you'll be at GNOME Boston summit, i'll be getting together with davidz and kay to discuess the future of hal and udev, and ways we can make it light
Sep 03 15:18:58 <RP> mickey|ICE79: I would like to see some kind of helper/companion application for OE which handles some of our machine specific issues. formfactor in poky is part of the problem/solution, neod another and zaurusd another. I have a grand vision of all these being merged...
Sep 03 15:19:18 <RP> mickey|ICE79: The end result might be something OE specific which feeds data to something like HAL/OHM
Sep 03 15:19:24 <robtaylor> mickey|ICE79: i'll be especially pushing for the ability to statically define what devices we have
Sep 03 15:20:05 <robtaylor> RP: is there anything I could do in OHM to help?
Sep 03 15:21:40 <RP> robtaylor: I think we need so have some kind of plugin which support the notion of a "machine". Things like a machine name (spitz, gta01), hardware group name (zaurus, omoko) and then various properties like screen dpi
Sep 03 15:21:42 <hrw> bb in 20m
Sep 03 15:22:37 <koen> RP: don't forget default rotation
Sep 03 15:23:21 <RP> robtaylor: This and information like the keyboard position in relation to the screen and framebuffer rotation are all information that's currently missing from the system at the moment. OE knows about them but has no way to communicate it
Sep 03 15:23:27 <robtaylor> RP: well, machine name and hardware platform are exposed in hal
Sep 03 15:23:47 <robtaylor> RP: its just a matter of adding an fdi for your hardaware
Sep 03 15:24:18 <RP> robtaylor: We need to create some kind of link between OE's information and these fdi files then
Sep 03 15:24:20 <robtaylor> RP: I guess it'd make sense to add all this info to the system namespace in hal
Sep 03 15:24:53 <robtaylor> RP: yep. You could generate it magically with a bit of elementree magic
Sep 03 15:25:21 <RP> robtaylor: The other issue is we need some of this before we can start the splash screen for example :/
Sep 03 15:25:58 <robtaylor> RP: what point in boot is the splash screen displayed?
Sep 03 15:26:18 <RP> robtaylor: before udev just after init
Sep 03 15:26:30 <robtaylor> RP: ah :/
Sep 03 15:27:05 <RP> robtaylor: This is why zaurusd/formfactor provide shell access to variables...
Sep 03 15:27:27 <koen> hal2shell :)
Sep 03 15:27:35 <robtaylor> RP: i guess thats because udevd takes ages to start:/
Sep 03 15:27:42 <RP> robtaylor: yes
Sep 03 15:28:01 <RP> We want the progress bar displayed while its doing its games...
Sep 03 15:28:31 <robtaylor> RP: well, there's no reason not to have that information written out in two places
Sep 03 15:28:55 <RP> robtaylor: No, but I just want it maintained in one place
Sep 03 15:29:00 <XorA> time for hal.ko :-)
Sep 03 15:29:13 <robtaylor> RP: you could borrow a page from hal- the fdi's are parsed and written out as binary chunks
Sep 03 15:29:36 <robtaylor> RP: it'd be plausible to load the relevent binary chunk at boot
Sep 03 15:30:18 <RP> robtaylor: Or do it at build time to build a cache of the values we know we need early in boot...
Sep 03 15:30:51 <robtaylor> RP:yep, there's a tool to generate the binary chunks at build/packagien install time
Sep 03 15:31:43 <robtaylor> RP: at boston we'll be talking about ways to combine the udev rules and the hal fdi's. I'll bring this up as a usecase
Sep 03 15:32:23 <RP> robtaylor: One thing I've love to also see is the ability to only include data relavent to machines X, Y and Z...
Sep 03 15:32:35 <RP> robtaylor: (as a compile time option)
Sep 03 15:32:43 <robtaylor> RP: in what way exactly?
Sep 03 15:33:11 <RP> robtaylor: There is no point installing machine information about a neo onto my zaurus
Sep 03 15:33:27 <robtaylor> RP: well, thats a matter for packagers
Sep 03 15:33:58 <robtaylor> RP: just install the fdi's that are needed for the hardware
Sep 03 15:34:50 <RP> robtaylor: It means writing some fairly elaborate packaging around hal which then makes you wonder why you don't write something more suited directly to OE's usecases :/
Sep 03 15:35:26 <RP> robtaylor: I'm not claiming any one approach is right here btw, just thinking out loud
Sep 03 15:35:38 <robtaylor> RP: would it? OE'd be generating the fdis for hardware description
Sep 03 15:35:54 <interfaith> anyone doing ixp4xx ?
Sep 03 15:36:14 <RP> robtaylor: I guess if OE is writing the fdi's that different
Sep 03 15:36:36 <robtaylor> RP: I can't think of any other sensible way to do it =)
Sep 03 15:37:27 <robtaylor> RP: like on N800, its nokias hal packages that install their machine description fdi, its nothing to do with hal upstream
Sep 03 15:37:46 <RP> robtaylor: I didn't know that...
Sep 03 15:38:00 <robtaylor> RP: and as for hal-info, OE already knows it doesnt need thinkpad and asus workarounds ;)
Sep 03 15:38:00 <RP> robtaylor: I know the kernel side of things better than userspace :/
Sep 03 15:38:20 <robtaylor> RP: heh, i know userspace better than kernel =)
Sep 03 15:38:54 <RP> robtaylor: You'd agree we need something fairly closely hooked into OE to make this work well then?
Sep 03 15:38:58 <robtaylor> RP: the other option is of course to define the infomation in the kernel and expose it in sysfs
Sep 03 15:39:23 <robtaylor> RP: yeah, if OE has the info, it needs a good way to get it out
Sep 03 15:39:42 <RP> But should the kernel be taught things like this when it doesn't need to know them. Its userspace that really needs to know, not the kernel...
Sep 03 15:39:55 <robtaylor> RP: indeed, i was just about to say the same thing :)
Sep 03 15:40:26 <RP> I'd much prefer to see hal learn to accept suplimentry data (or if it already does in the form of fdi files, teach systems to generate them)
Sep 03 15:41:00 <robtaylor> RP: yep, it already does, you can arbiarily manipulate the device space with fdis
Sep 03 15:41:55 <robtaylor> RP: so I'd say getting OE to generate the relevent keys on the /org/freedesktop/Hal/devices/computer would be a nice way forward
Sep 03 15:42:37 <robtaylor> and we propose some standard keys in the hal spec for things that arent there yet
Sep 03 15:42:45 <RP> robtaylor: yes, I agree
Sep 03 15:42:58 <RP> robtaylor: Where would you see something like tskeys fitting into this?
Sep 03 15:43:17 <robtaylor> RP: tskeys?
Sep 03 15:43:40 <RP> tskeys implements soft 'keys' on a touchscreen matrix by feeding key events into the kernel when defined areas of a touchscreen are touched
Sep 03 15:44:06 <RP> The zaurus has such key areas marked on the touchscreen which is bigger than the screen
Sep 03 15:44:08 <robtaylor> RP: ah, so they appear in the kernel input subsystem right?
Sep 03 15:44:13 <RP> yes
Sep 03 15:44:26 <robtaylor> RP: so they'll give button events on hal automatically
Sep 03 15:44:37 <robtaylor> thats should just work (tm)
Sep 03 15:44:40 <RP> In some senses its a standalone daemon but where do things like this fit into hal/ohm
Sep 03 15:45:15 <RP> It needs to know which device its running on to know whether it should run and in what configuration
Sep 03 15:45:21 <robtaylor> RP: run hald on a machine with tskeys and lshal -m and give it check
Sep 03 15:45:45 <robtaylor> RP: no other daemon needed other than hal, its already exposing the button on dbus
Sep 03 15:46:02 <RP> robtaylor: I don't doubt the buttons get seen by hal, thats fine. I'm just wondering where we stick daemons like this
Sep 03 15:46:19 <RP> Presumably its outside the scope of OHM?
Sep 03 15:46:21 <robtaylor> RP: what's the extra daemon for?
Sep 03 15:46:53 <RP> robtaylor: Listen for touchscreen events, see if they're over the touchscreen softkeys, if so inject a keypress into the kernel
Sep 03 15:47:13 <RP> it uses uinput
Sep 03 15:47:19 <robtaylor> RP: ahh, i see
Sep 03 15:47:38 <RP> Its in userspace since it only works once you have the screen calibration data
Sep 03 15:48:13 <robtaylor> RP: yeah, i think thats a seperate daemon
Sep 03 15:49:02 <robtaylor> RP: how are the key areas defined?
Sep 03 15:49:14 <RP> robtaylor: At present they have a simple conf file
Sep 03 15:50:10 <robtaylor> RP: yeah, that sounds all sensible to me. Its outside the scope of ohm, for sure. thats abour hardware state management
Sep 03 15:50:54 <RP> robtaylor: So you'd agree that if we wanted to collect machine specific feature handling code like this it would be a separate project?
Sep 03 15:51:22 <robtaylor> RP: though there's actually no reason it couldn't be an ohm plugin, not sure if it makes sense or not though
Sep 03 15:52:54 <RP> How would/does ohm plan to handle the packaging issue that such code would cause? (not every user is going to want these features) 
Sep 03 15:53:04 <RP> configure options?
Sep 03 15:53:11 <robtaylor> RP: so far, yes
Sep 03 15:53:34 <RP> So something like OE is going to have to pass different configure options for each  machine?
Sep 03 15:53:43 <robtaylor> RP: or by having packagers install a differet ohm.conf
Sep 03 15:54:10 <RP> but that means lots of people would have a plugin around they didn't need...
Sep 03 15:54:20 <robtaylor> RP: well, atm there's nothing very machine specific
Sep 03 15:54:43 <RP> No, I'm speaking hypothetically if something like tskeys were added
Sep 03 15:54:52 <RP> I'm just trying to work out where these things are best put...
Sep 03 15:55:07 <robtaylor> RP: ah. In that case, i'd actually have a different package provide the tskeys plugin
Sep 03 15:55:57 <robtaylor> RP: the plugin api should be relatively stable, and something doesnt need to be in the tree to build one
Sep 03 15:56:44 <RP> These plugins are going to be nearly one to one with features from the OE fdis...
Sep 03 15:57:51 <hrw> recent OE is broken - "bitbake autoconf" builds also m4 and gnu-config but they are not packaged etc - their tasks end when autoconf do do_build
Sep 03 15:58:16 <hrw> so to finish building them I need "bitbake autoconf m4 gnu-config"
Sep 03 15:58:39 <robtaylor> RP: not sure what you're suggesting!
Sep 03 15:59:43 <RP> robtaylor: I don't know myself. I honestly don't know where the code for these things should end up. I would like to see some kind of framework in place which allows it to be shared and resused though
Sep 03 16:00:03 <CIA-17> 03freyther 07org.oe.dev * r4555b836... 10/ (1 packages/qte/qtopia-core_4.3.1.bb): packages/qte/qtopia-core: Add QtopiaCore version 4.3.1
Sep 03 16:00:08 <RP> robtaylor: Its why I wrote zaurusd the way I did but nobody seems very keen on it ;-)
Sep 03 16:00:09 <CIA-17> 03freyther 07org.oe.dev * r14dd1ebc... 10/ (1 MAINTAINERS): MAINTAINERS: Add the Qtopia interest...
Sep 03 16:00:13 <RP> hrw: With rm_work?
Sep 03 16:00:42 <hrw> RP: without
Sep 03 16:01:46 <RP> hrw: Does it work as expected in poky?
Sep 03 16:02:09 <hrw> RP: checking
Sep 03 16:03:08 <robtaylor> RP: i should have a good read over of zaurusd ;)
Sep 03 16:03:09 <hrw> RP: same problem in poky
Sep 03 16:03:36 <RP> robtaylor: http://svn.o-hand.com/view/misc/trunk/zaurusd/
Sep 03 16:03:57 <interfaith> hrw: still here :) how to install modules to the file system ?
Sep 03 16:03:58 <RP> robtaylor: It was done with shell script although I'd intended it would ultimately feed the data over dbus too
Sep 03 16:04:08 <robtaylor> RP: i think at a base level, the distro has to be in charge of deciding what features/plugins a given build should have
Sep 03 16:04:24 <robtaylor> RP: it just need to be made easy for distros to do this
Sep 03 16:04:36 <RP> robtaylor: At the base level it comes down to the machine...
Sep 03 16:04:38 <interfaith> i need the network modules in the filesystem.. 
Sep 03 16:04:44 <robtaylor> RP: aye
Sep 03 16:05:08 <RP> robtaylor: dsitro determines the policy, machine governs  the actual hardware features...
Sep 03 16:05:09 <robtaylor> RP: well, its all sorted in the PC space by acpi
Sep 03 16:05:13 <hrw> interfaith: add them into MACHINE_EXTRA_RRECOMMENDS in machine.config and then clean task-boot/task-base/ and build image
Sep 03 16:06:08 <robtaylor> RP: and we need to have something roughly equivalent in the embedded space. Ideally just a single 'machine definition' file would be great
Sep 03 16:06:21 <hrw> robtaylor: x86 bios + acpi suxx very often ;(
Sep 03 16:06:25 <interfaith> super
Sep 03 16:06:34 <robtaylor> hrw: i'm not suggesting its not crap ;)
Sep 03 16:08:16 <robtaylor> RP: yeah, so hinge-handler's already done by ohm
Sep 03 16:09:00 <robtaylor> RP: maybe i should explain how the plugins split up a bit. There's two types: mechanism and policy
Sep 03 16:09:52 <robtaylor> RP: so mechanism exposes actions and state onto the ohm key space, and policy plugins link these together in some specific way 
Sep 03 16:11:31 <RP> robtaylor: That makes sense
Sep 03 16:12:23 <robtaylor> RP: so there's an xrandr plugin that exposes a key for screen rotation, and a button plugin that exposes hardware buttons
Sep 03 16:13:48 <RP> robtaylor: so a touchscreen plugin would be needed to tskeys...
Sep 03 16:13:49 <robtaylor> RP: and you could have a zaurus handler that connects these up to do the screen rotation right for zaurses
Sep 03 16:15:00 <robtaylor> RP: well, thats why i was saying i'm not sure tskeys fits in.
Sep 03 16:15:29 <robtaylor> RP: its already grand as a standalone daemon
Sep 03 16:16:06 <RP> robtaylor: Then we come to the ugly alsa mixer question :}
Sep 03 16:16:27 <robtaylor> RP: does it need to go away at times? One of the mechnism plugins i've got plans is one for starting/stopping daemons
Sep 03 16:16:43 <RP> robtaylor: Not really, it can just be active the whole time
Sep 03 16:17:14 <robtaylor> RP: ah, alsamixer. I think lrg and lennart poettering had some interesting plans for that
Sep 03 16:17:44 <RP> I've talked to lrg about it before and there are lots of ideas but no code yet afaik :/
Sep 03 16:17:51 <robtaylor> RP: i think themost that'd be needed at the OHM level would be a plugin for setting a profile
Sep 03 16:18:03 <RP> The handling in zaurusd has been a good stop gap solution
Sep 03 16:18:41 <RP> robtaylor: Its complicated by the fact we really need to ask the user what they plugged in (mic, headset, headphones)
Sep 03 16:18:55 <robtaylor> RP: then a policy plugin can do things like 'bluetooth headset? set profile 'foo''
Sep 03 16:18:56 <RP> robtaylor: The hardware supports them but can't autodetect
Sep 03 16:19:27 <robtaylor> RP: that's abit of a stinker!
Sep 03 16:21:48 <lrg> RP, robtaylor: sadly the alsamixer changes have been very low on my todo list lately with customer work having to come first (there even lower now until I can hire another engineer) :/ 
Sep 03 16:21:56 <robtaylor> RP: thats a real hard one to do nicely
Sep 03 16:21:59 <robtaylor> lrg: hey!
Sep 03 16:22:16 <robtaylor> lrg: i don't suppose you have a write-up of the plans?
Sep 03 16:22:43 <lrg> RP, robtaylor: fwiw I think the openmoko folks will end up doing this (as they need it first)
Sep 03 16:23:06 <lrg> robtaylor: I could send an email out of what needs done.
Sep 03 16:23:43 <RP> robtaylor: zaurusd just calls a binary to say a choice is needed. It then accepts calls with the mode. Sadly the choice application never got written but all the lower infrastructure is there
Sep 03 16:25:37 <robtaylor> lrg: that'd be nice :)
Sep 03 16:26:12 <robtaylor> RP: I guess the same's be possible in OHM
Sep 03 16:26:47 <robtaylor> RP: the app could just write the relevent key itself and exit
Sep 03 16:27:16 <RP> robtaylor: yes
Sep 03 16:28:25 <hrw> bye
Sep 03 16:34:03 <Jin^eLD> re
Sep 03 16:47:14 <zap> Evening! Angstrom is able to use the built-in flash memory of SL-C3200? What's the reson it is put on /dev/hda1?
Sep 03 16:54:29 <florian> re
Sep 03 16:54:48 <florian> mickey|zzZZzz: sure :-)
Sep 03 17:08:18 <Marex> can anyone explain me why cant I build libqpe-opie ? I was able to build it a few hours ago...
Sep 03 17:08:25 <Marex> the important part is probably ...
Sep 03 17:08:26 <Marex> OpenEmbedded/build/tmp/work/armv5te-angstrom-linux-gnueabi/libqpe-opie-1.2.3+cvs20070903-r1/temp/run.do_configure.19105: line 491: qmake-base_do_configure: command not found
Sep 03 17:09:00 <Marex> well it has something to do with recent changes in qmake-base.bbclass I think
Sep 03 17:09:28 <Marex> polyonymous_, :)
Sep 03 17:11:04 <polyonymous_> Marex, sounds like zecke's changes, I think I have to look into it then :(
Sep 03 17:12:35 <Marex> polyonymous_, thanks a lot :)
Sep 03 17:13:02 <polyonymous_> I didn't say I'm going to do that immediately, though ;-)
Sep 03 17:13:27 <polyonymous_> (but I'll try asap)
Sep 03 17:13:36 <Marex> polyonymous_, np ;)
Sep 03 17:13:41 <Marex> thanks anyway :)
Sep 03 17:13:51 <polyonymous_> Marex, I think I'll go for thinkpad R60, btw ;-)
Sep 03 17:14:13 <Marex> polyonymous_, well ... my A7Tc died recently (damn :/)
Sep 03 17:14:15 <florian> RP, zecke_: iirc one of you is the RDEPENDS magic guru... bitbake 1.8.9 does not seem to be able to find the bb that provides libglib-2.0-utils.
Sep 03 17:15:06 <polyonymous_> Marex, I will not go for asus again anytime soon ;-)
Sep 03 17:15:28 <Marex> polyonymous_, same here :T
Sep 03 17:16:56 <interfaith> is bitbake task-base -c clean ok ?
Sep 03 17:17:13 <koen> florian: because it's called 'glib-2.0-utils' properly?
Sep 03 17:19:10 <florian> koen: wel.. the package is "libglib-2.0-utils" and it does not specify a "provides" field, but yes imho it _should_ be named "glib-2.0-utils".
Sep 03 17:19:25 <koen> you don't understand
Sep 03 17:19:48 <koen> it's called 'glib-2.0-utils' in OE and debian.bbclass renames it to libglib-2.0-utils
Sep 03 17:20:13 <koen> so you should RDEPENDS = "glib-2.0-utils" and OE will automatically correct that if you use debian.bbclass
Sep 03 17:22:12 <florian> koen: ok, but shouldn't oe consider this changed name in this case too? 
Sep 03 17:22:43 <koen> how can it know that in advance?
Sep 03 17:23:01 <koen> you have to build the shared lib before knowing how to rename it
Sep 03 17:23:19 <koen> and doing RDEPENDS = "libglib-2.0-utils" breaks for people not using debian.bbclass
Sep 03 17:37:19 <m4rz> hi to all
Sep 03 17:37:26 <m4rz> someone have zaurus c760
Sep 03 17:49:44 <XorA> morning
Sep 03 17:50:12 <interfaith> afternoon here
Sep 03 17:50:28 <koen> ~ugt
Sep 03 17:50:29 <ibot> from memory, ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html
Sep 03 17:50:38 <koen> XorA: cloned yourself?
Sep 03 17:50:59 <XorA> koen: not that I remeber
Sep 03 17:51:25 <koen> XorA: http://www.flickr.com/photos/koenkooi/1288734244/
Sep 03 17:52:09 <koen> XorA: do you remember the details about bluez-gnome and nautilus?
Sep 03 17:52:34 <XorA> koen: there is supposed to be a gnome-vfs plugin
Sep 03 17:52:59 <robtaylor> koen: nice pictures :)
Sep 03 17:53:10 <koen> XorA: http://www.openembedded.org/repo/org.openembedded.dev/packages/gnome/gnome-vfs-obexftp_0.4.bb
Sep 03 17:53:16 <koen> robtaylor: thanks :)
Sep 03 17:53:25 <XorA> koen: that looks like the one
Sep 03 17:54:13 <koen> wth? bluez 3.18
Sep 03 17:54:38 <XorA> I guess too many bugs :-)
Sep 03 17:56:11 <koen> static gboolean obexftp_available(void)
Sep 03 17:56:12 <koen> {
Sep 03 17:56:12 <koen>         path = g_find_program_in_path("nautilus");
Sep 03 17:56:12 <koen>         if (path == NULL)
Sep 03 17:56:12 <koen>                 return FALSE;
Sep 03 17:56:12 <koen>         return TRUE;
Sep 03 17:56:13 <koen> }
Sep 03 17:56:21 <interfaith> after task-base -c clean.. then ERROR no providers  ? some fix ?
Sep 03 18:03:30 <koen> hey mallum & pH5 
Sep 03 18:04:00 <pH5> hej koen
Sep 03 18:07:23 <koen> XorA: 'touch /usr/bin/nautilus ; chmod +x /usr/bin/nautilus' makes bluez-gnome work :)
Sep 03 18:09:49 <XorA> koen: thats really bad coding :-)
Sep 03 18:10:35 <zap> Is there a keymap for X11/Angstrom which corresponds to the normal SL-C3200 mapping? Currently Fn does not work, arrows too and other keys as well.
Sep 03 18:12:21 <XorA> zap: thats a bug that we are trying to find
Sep 03 18:12:28 <XorA> zap: run /etc/init.d/keymap
Sep 03 18:12:32 <XorA> zap: then restart X
Sep 03 18:12:47 <XorA> zap: of course to make things interesting / doesnt work
Sep 03 18:12:57 <zap> yep, thats one of the worse features :)
Sep 03 18:13:08 <zap> Isnt it because of a wrong xkb map?
Sep 03 18:13:18 <XorA> .. tab .. tab etc tab init.d tab keymap
Sep 03 18:13:23 <koen> cd . ; cd . ; etc/init.d/keymap
Sep 03 18:13:33 <XorA> zap: no, its because kernel keymap never got loaded
Sep 03 18:13:47 <zap> aha
Sep 03 18:14:01 <zap> I can cd using mc :)
Sep 03 18:14:03 <XorA> koen: you fail at linux :-)
Sep 03 18:15:45 <zap> btw is there a way to mirror angstrom feeds somehow? Mirroring through http isn't a good idea
Sep 03 18:20:18 <koen> XorA: bluez-gnome calls nautilus with '--no-default-window obex://[00:17:F2:A1:32:DA]'
Sep 03 18:21:18 <steliosk> zap : There is rsync running, but talk to koen about a read only account/set up
Sep 03 18:37:56 <koen> XorA: if gpe-filemanager could take URIs from CMDLINE we could have browsing working :)
Sep 03 18:40:55 <XorA> koen: heh heh
Sep 03 18:41:31 * XorA will have to give it a go sometime with his usbbt
Sep 03 18:43:10 * XorA builds a dragon
Sep 03 19:05:11 <interfaith> any bit baker ?
Sep 03 19:16:12 <interfaith> bitbake task-base -c clean makes trouble  how to recover re install all ?
Sep 03 19:16:24 <XorA> koen: yay, my wlan connects with my access point now
Sep 03 19:20:42 <koen> XorA: :)
Sep 03 19:21:19 <XorA> yeah 1.8.4 was severly bolloxed, it didnt even allow setting encryption key properly
Sep 03 19:22:22 <XorA> ~fish lrg 
Sep 03 19:22:23 * ibot slaps lrg around with a large trout
Sep 03 19:24:53 <lrg> XorA: ouch
Sep 03 19:25:41 <XorA> lrg: 15 days left of that :-)
Sep 03 19:26:01 <lrg> heh
Sep 03 19:27:48 <koen> XorA: http://shop.lego.com/ByTheme/Product.aspx?p=4958&cn=348&d=70 :)
Sep 03 19:35:00 <interfaith> any  bit baker in the kitchen ?
Sep 03 19:41:24 <interfaith> oe hello 
Sep 03 19:44:50 <dcordes> omg monster dino
Sep 03 19:45:04 <dcordes> get some mindstorms, XorA 
Sep 03 19:46:30 <XorA> dcordes: got mindstorms 1.5
Sep 03 19:47:57 <hrw> hi
Sep 03 19:48:12 <dcordes> XorA: I also have it but sold my rcx
Sep 03 19:48:23 <dcordes> :(
Sep 03 19:48:49 * hrw bought case for alix board
Sep 03 19:49:21 <koen> lunch box?
Sep 03 19:49:51 <XorA> lego do some nice lunch boxes :-)
Sep 03 19:50:18 <hrw> http://www.ikea.com/pl/pl/catalog/products/10073345
Sep 03 19:50:33 <hrw> ~4 EUR
Sep 03 19:51:07 <dcordes> good thing is you can take out the seperator things so you have one big box :D
Sep 03 19:53:22 <hrw> dcordes: only one needs to be removed - alix is 17x17 (miniitx) only
Sep 03 19:53:26 <chouimat> nice 6.99cad
Sep 03 19:56:09 <hrw> I need to check do I have proper amount of screws to mount mainboard
Sep 03 19:56:21 <hrw> but that tomorrow
Sep 03 20:00:24 <XorA> hmm, Ive managed to white out my screen akita style
Sep 03 20:00:41 <dcordes> akita style?
Sep 03 20:00:48 <CIA-17> 03mickeyl 07org.oe.dev * rfaad8a35... 10/ (4 files in 3 dirs): official ezx name for the ROKR E2 is rokre2 (yes it looks ugly... ;)
Sep 03 20:00:53 <CIA-17> 03mickeyl 07org.oe.dev * r7eb72993... 10/ (1 packages/openmoko2/openmoko-mediaplayer2_svn.bb): openmoko-mediaplayer2: add dependency on gst-meta-audio
Sep 03 20:01:00 <CIA-17> 03mickeyl 07org.oe.dev * rd17e4c23... 10/ (1 packages/openmoko2/libmokopanelui2_svn.bb): libmokopanelui2: add new dependency on matchbox-panel-2
Sep 03 20:01:10 <dcordes> ezx in oe?
Sep 03 20:01:20 <hrw> libmokopanelui2 depend on mb-panel2?
Sep 03 20:02:01 <CIA-17> 03hrw 07org.oe.dev * rfc124182... 10/ (1 packages/samba/samba.inc packages/samba/samba_3.0.23c.bb): samba: depend on virtual/libiconv and supply path to it to fix building - taken from #2900
Sep 03 20:04:13 <hrw> mickey|zzZZzz: DEPENDS?? should not it be RDEPENDS?
Sep 03 20:08:25 <mwester> hrw:  It appears to be a build-time dependency (configure script fails) -- isn't that a DEPENDS?
Sep 03 20:09:25 <riot> how many LOC does OE have?
Sep 03 20:09:42 <koen> it isn't a lib, so you can't link against it, so RDEPENDS should be the thing
Sep 03 20:09:50 <hrw> mwester: interesting
Sep 03 20:09:55 <hrw> riot: ?
Sep 03 20:10:14 <koen> riot: it's 180MB
Sep 03 20:10:36 <riot> koen: only the source?
Sep 03 20:11:48 <koen> riot: go read http://www.openembedded.org/project-overview and http://www.openembedded.org/user-manual&dpage=chapter_introduction
Sep 03 20:11:53 <hrw> koen: PKG_CHECK_MODULES(DEPS, matchbox-panel )
Sep 03 20:12:04 <koen> hrw: weird
Sep 03 20:12:53 <hrw> indeed
Sep 03 20:13:46 <hrw> especially when you look at matchbox-panel.pc - it only give gtk/glib requires and normal includedir
Sep 03 20:14:01 <RP> XorA: For a minute I wondrered how bitbake 1.8.4 was bolloxed :)
Sep 03 20:14:42 <riot> koen: oh..thanks.. So, wrong question in the wrong channel :)
Sep 03 20:14:50 <RP> damn scrollback :/
Sep 03 20:16:37 <XorA> RP: you have bitbake on the brain :-)
Sep 03 20:17:08 <XorA> koen: does rox-filer take args and use gnome-vfs?
Sep 03 20:17:36 <hrw> XorA: takes but rather do not use
Sep 03 20:17:38 <RP> XorA: The bit at the bottom of my screen was "yeah 1.8.4 was severly bolloxed" and you're right, I think I need a holiday :/
Sep 03 20:20:02 <Marex> polyonymous_, ok, I think I fixed the problem
Sep 03 20:20:12 <Marex> polyonymous_, well ... dunno if I can call it a fix :/
Sep 03 20:20:37 <polyonymous_> Marex, ah, I haven't even looked at it.
Sep 03 20:20:43 <polyonymous_> Marex, what was the package again?
Sep 03 20:20:52 <Marex> libqpe-opie
Sep 03 20:21:05 <hrw> koen:  Depends: gtk+ (>= 2.10.14), libatk-1.0-0 (>= 1.10.3), libc6 (>= 2.5), pango (>= 1.16.4), libcairo2 (>= 1.4.10), libglib-2.0-0 (>= 2.12.12), libgcc1 (>= 4.1.2)
Sep 03 20:21:06 <polyonymous_> baking... I've just pulled and updated.
Sep 03 20:21:14 <hrw> koen: I do not see mb-panel2 in it...
Sep 03 20:21:36 <Marex> polyonymous_, well ... the fix is that I renamed opie-base.bbclass to opie_base.bbclass and also changed all inherits from opie-base to opie_base
Sep 03 20:21:40 <Marex> polyonymous_, now it works ;)
Sep 03 20:21:53 <polyonymous_> Marex, doesn't sound good ;-)
Sep 03 20:22:11 <Marex> probably it has some issues with "-" ;-)
Sep 03 20:22:18 <Marex> poor "-", what a discrimination
Sep 03 20:22:18 <XorA> RP: ok, keymap problem is due to missue device in rootfs
Sep 03 20:22:21 <polyonymous_> what has some issues with "-" ?
Sep 03 20:22:25 <XorA> RP: running it after udev works
Sep 03 20:22:28 <Marex> bitbake ?
Sep 03 20:22:31 <polyonymous_> hmm
Sep 03 20:22:41 <XorA> RP: so I guess your makedevs fix probably does the trick for new images
Sep 03 20:23:07 <RP> XorA: Maybe, maybe not. It depends extactly what the problem is
Sep 03 20:23:12 <polyonymous_> Marex, tried ls classes/*-* ? :)
Sep 03 20:23:21 <RP> XorA: The makedevs change introduced a raft of subtle problems :/
Sep 03 20:23:44 <Marex> polyonymous_, yup, but none of those that contain "-" in their names do EXPORT_FUNCTION
Sep 03 20:24:05 <polyonymous_> ah
Sep 03 20:24:06 <polyonymous_> hm
Sep 03 20:24:35 <polyonymous_> why don't you poke, for instance RP, in his ribs? :)
Sep 03 20:25:14 <polyonymous_> well... anyway, I'll look at it...
Sep 03 20:25:59 <Marex> polyonymous_, thanks :)
Sep 03 20:26:44 <XorA> I suspect missing /dev/tty and /dev/tty0 to be precise
Sep 03 20:27:27 <polyonymous_> Marex, could that be a shell problem, btw?
Sep 03 20:27:31 <XorA> hmm /dev/ before uboot is kinda empty :-)
Sep 03 20:28:13 <Marex> polyonymous_, I doubt so ... Im using somehow standard bash from debian
Sep 03 20:28:43 <polyonymous_> Marex, well, I didn't know what you're using :)
Sep 03 20:29:40 <Marex> I thought you were a clairvoaynte ;-)
Sep 03 20:30:00 <polyonymous_> once upon a time :)
Sep 03 20:30:06 <Marex> :)
Sep 03 20:30:16 <Marex> http://marex.hackndev.com/qmake_base.patch this is the garbage called patch ;)
Sep 03 20:30:27 <Marex> it somehow made libqpe-opie to compile again
Sep 03 20:30:49 <polyonymous_> Marex, I hope that's not the only way...
Sep 03 20:31:34 <Marex> polyonymous_, it's just a rename ... I know it's far from correct though ;)
Sep 03 20:31:57 <polyonymous_> Marex, I know it's just a rename, but... well, we'll see
Sep 03 20:32:09 <Marex> sure :)
Sep 03 20:32:13 <polyonymous_> I'm so far behind that I'm recompiling gcc after the pull :)
Sep 03 20:32:29 <Marex> hehe ;)
Sep 03 20:32:40 <Marex> btw I forgot to add Im compiling angstrom 2008.1 ;)
Sep 03 20:33:27 <polyonymous_> uh, I'm not. yet :)
Sep 03 20:35:19 <hrw> RP: does package_write_ipk needs to be addtasked?
Sep 03 20:37:17 <hrw> mwester: can you update madwifi-ng to 2702-20070903? r2518 which is in OE do not builds again 2.6.23-rc3
Sep 03 20:50:54 <zecke_> koen: ping
Sep 03 20:51:57 <zecke_> koen: I'm reading the GCC summit 2003 papers and the first one is about code size
Sep 03 20:52:26 <mwester> hrw: I'll give it a try.
Sep 03 20:54:27 <hrw> thx
Sep 03 20:54:58 <hrw> mwester: also check PR settings - all releases has PR = "r0" set but common include set it to r5 anyway
Sep 03 20:55:58 <mwester> Should we change that?  (can we change that without breaking anything else?)
Sep 03 20:56:53 * mwester wishes that we numbered PRs differently, such as <PR-include>.<PR-major> so that we could change either with finer granularity
Sep 03 20:56:54 <hrw> in new recipes set PR after require line
Sep 03 20:57:04 <mwester> Ok.  That'll work
Sep 03 20:58:40 <mwester> My build machine is tied up right now, it'll have to wait for a few hours.
Sep 03 20:58:49 <hrw> no problem
Sep 03 20:59:00 <hrw> I do not use those drivers anyway
Sep 03 20:59:32 <CIA-17> 03cbrake 07org.oe.dev * reaba92e0... 10/ (1 packages/images/angstrom-minimal-image-with-mtd-utils.bb): angstrom-minimal-image-with-mtd-utils.bb: set image base name
Sep 03 20:59:39 <CIA-17> 03cbrake 07org.oe.dev * ra79e5ae3... 10/ (11 files in 4 dirs): mono 1.2.5: add 1.2.4, drop 1.2.5-pre5
Sep 03 20:59:45 <hrw> but Ania as such card (atheros) in her laptop so I can take it off probably and check in alix
Sep 03 21:09:01 <polyonymous_> Marex, built fine here...
Sep 03 21:09:20 <Marex> hm :(
Sep 03 21:09:42 <polyonymous_> hm. I think I lied, lemme try -c rebuild.
Sep 03 21:09:59 <polyonymous_> I think it's only run do_stage
Sep 03 21:10:15 <Marex> Im rebuilding from scratch and going to bed :)
Sep 03 21:10:31 <Marex> gnight and thanks polyonymous_ ;)
Sep 03 21:10:35 <polyonymous_> yeah, Marex, fails fine :)
Sep 03 21:10:52 <Marex> polyonymous_, damn :T
Sep 03 21:11:19 <Marex> Im nearly unconscious ... gnight
Sep 03 21:11:24 <polyonymous_> night
Sep 03 21:25:55 <hrw> bye
Sep 03 22:52:42 <Crofton|home> gumstix have arrived
Sep 03 22:53:02 <sakoman> Crofton: woo hoo!
Sep 03 22:54:03 <Crofton|home> I'll try and get it booting in the morning
Sep 03 22:54:18 <Crofton|home> things may get crazy though 
Sep 03 22:54:28 <Crofton|home> may have to go to Toronto soon
Sep 03 22:54:37 <sakoman> Not surprising, you've been away :-)
Sep 03 22:54:51 <sakoman> Biz or pleasure?
Sep 03 23:52:26 <Crofton|home> sakoman, now I ned to figure out how this gumstix stuff goes together
Sep 04 00:10:15 <rwhitby> should libsdl-x11.bb be updated to stage the sdl-config script?
Sep 04 00:10:25 <rwhitby> (otherwise scummvm doesn't build)
Sep 04 00:45:37 <interfaith> rwhitby:any hints on getting the network up ?
Sep 04 00:45:56 <interfaith> ifconfig shows no devices , only lo
Sep 04 00:47:56 <interfaith> compiling in kernel all NPE network drivers does not change a thing
Sep 04 00:48:57 <interfaith> rwhitby: redboot gets the network, linux cannot ? 
Sep 04 00:51:46 <rwhitby> interfaith: sorry, but I simply don't have the time to help you with this.
Sep 04 00:51:59 <interfaith> ok.. thx
Sep 04 00:52:42 <interfaith> i'll let you know if something washes out
Sep 04 00:52:50 <rwhitby> it's just too difficult without the board in front of me.
Sep 04 00:55:35 <interfaith> one other issue , bitbake task-base -c clean , then the provider for task-base is lost
Sep 04 00:55:42 <interfaith> can this be recovered ?
Sep 04 00:57:03 <rwhitby> I have no idea what you're talking about there.
Sep 04 00:57:56 <interfaith> ok , bitbake task-base normaly works fine, but now errors saying no provider is found
Sep 04 00:58:26 <interfaith> this error came after doing a bitbake task-base -c clean
Sep 04 00:58:47 <interfaith> i will paste bin it
Sep 04 01:01:22 <interfaith> pastebin.ca/680567
Sep 04 01:02:18 <interfaith> if need be i will re-install
Sep 04 01:04:43 <m9dhatter> hello. the oe wiki seems to be broken. i didn't know where else to report it. since its not really an OE bug. the wiki displays links with <a href="">text</a>
Sep 04 01:27:26 <CIA-17> 03rwhitby 07org.oe.dev * r98e5d691... 10/ (1 packages/scummvm/scummvm.inc): 
Sep 04 01:27:26 <CIA-17> scummvm: Put it back the (broken) way it was. Changing to STAGING_BINDIR_CROSS
Sep 04 01:27:26 <CIA-17> doesn't help, cause that doesn't end in a 'bin' directory, and the configure
Sep 04 01:27:26 <CIA-17> script in scummvm adds a 'bin' to the end of the prefix given. Someone else who
Sep 04 01:27:26 <CIA-17> cares will need to fix it properly.
Sep 04 01:27:32 <CIA-17> 03rwhitby 07org.oe.dev * r98e5d691... 10/ (1 packages/scummvm/scummvm.inc): 
Sep 04 01:27:34 <CIA-17> scummvm: Put it back the (broken) way it was. Changing to STAGING_BINDIR_CROSS
Sep 04 01:27:36 <CIA-17> doesn't help, cause that doesn't end in a 'bin' directory, and the configure
Sep 04 01:27:38 <CIA-17> script in scummvm adds a 'bin' to the end of the prefix given. Someone else who
Sep 04 01:27:40 <CIA-17> cares will need to fix it properly.
Sep 04 01:27:42 <CIA-17> 03rwhitby 07org.oe.dev * r98e5d691... 10/ (1 packages/scummvm/scummvm.inc): 
Sep 04 01:27:44 <CIA-17> scummvm: Put it back the (broken) way it was. Changing to STAGING_BINDIR_CROSS
Sep 04 01:27:46 <CIA-17> doesn't help, cause that doesn't end in a 'bin' directory, and the configure
Sep 04 01:27:47 <CIA-17> script in scummvm adds a 'bin' to the end of the prefix given. Someone else who
Sep 04 01:27:49 <CIA-17> cares will need to fix it properly.
Sep 04 01:28:03 <CIA-17> 03rwhitby 07org.oe.dev * r98e5d691... 10/ (1 packages/scummvm/scummvm.inc): 
Sep 04 01:28:03 <CIA-17> scummvm: Put it back the (broken) way it was. Changing to STAGING_BINDIR_CROSS
Sep 04 01:28:03 <CIA-17> doesn't help, cause that doesn't end in a 'bin' directory, and the configure
Sep 04 01:28:03 <CIA-17> script in scummvm adds a 'bin' to the end of the prefix given. Someone else who
Sep 04 01:28:03 <CIA-17> cares will need to fix it properly.
Sep 04 01:28:39 <CIA-17> 03rwhitby 07org.oe.dev * r64fd2558... 10/ (1 packages/tasks/task-openmoko-feed.bb): task-openmoko-feed: Removed scummvm cause it's broken and too hard for me to fix.
Sep 04 02:25:05 <mwester> hrw|gone:  Added madwifi-ng_r2702-20070903.bb -- Preference = -1, because it won't build on BE kernels (undefined references).  The modules load ok on an LE 2.6.21 kernel, though.
**** ENDING LOGGING AT Tue Sep 04 02:59:56 2007