**** BEGIN LOGGING AT Sat Oct 27 02:59:56 2007
Oct 27 05:44:33 <Zero_Chaos> RP: ping
Oct 27 07:07:41 <steliosk> good morning all
Oct 27 07:09:04 <cdbot2> * * OE Bug 3216 has been created by hvontres(AT)gmail.com
Oct 27 07:09:06 <cdbot2> * * linux-rp-2.6.23: fixed defconfig.  poodle and a patch for sound/soc/pxa/poodle.c
Oct 27 07:09:08 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=3216
Oct 27 07:50:26 <zap> Hmm, what's the difference between gpe.linuxtogo.org and gpe.handhelds.org?
Oct 27 07:51:20 <zap> Is this a split?
Oct 27 09:35:33 <RP> morning all
Oct 27 09:35:59 <micropal_> morning ;)
Oct 27 11:15:13 <gilligan_> hi
Oct 27 11:16:08 <gilligan_> cbrake_away, building the kernel for cmx270 with pcmcia modules works just fine. I can send you the changes to defconfig on monday if you want
Oct 27 12:15:04 * steliosk pushes changes to gcc-package-cross.inc and hides
Oct 27 12:33:12 <CIA-31> 03ifaistos 07org.oe.dev * r91207b51... 10/ (1 packages/grdesktop/grdesktop_0.23.bb): packages/grdesktop/grdesktop_0.23.bb : Set RDEPENDS
Oct 27 12:33:18 <CIA-31> 03ifaistos 07org.oe.dev * rdf031d24... 10/ (1 conf/machine/include/tune-ppc405.inc): 
Oct 27 12:33:18 <CIA-31> conf/machine/include/tune-ppc405.inc : Move TARGET_FPU = "soft" to the tune file so its
Oct 27 12:33:18 <CIA-31> get used by all machines that have a amcc405 cpu
Oct 27 12:33:29 <CIA-31> 03ifaistos 07org.oe.dev * r182f45ef... 10/ (4 files in 2 dirs): 
Oct 27 12:33:29 <CIA-31> packages/gcc/gcc-package-cross.inc : Fix to handle /nof/ dirs generated by some ppc
Oct 27 12:33:29 <CIA-31> architectures
Oct 27 12:33:29 <CIA-31> packages/gcc/gcc-cross_4.1.1.bb : Bump PR
Oct 27 12:33:29 <CIA-31> packages/gcc/gcc-cross_4.1.2.bb : Bump PR
Oct 27 12:55:13 * Crofton|home nukes tmp and starts a build ...
Oct 27 12:56:24 <hrw|gone> XorA|gone: please add gst-plugin-pulse into RDEPENDS of openmoko-mediaplayer - it does not run without it.
Oct 27 12:56:30 <hrw|gone> XorA|gone: I will create bg for it
Oct 27 12:56:36 <hrw|gone> s/bg/bug
Oct 27 12:58:31 * stappers doesn't get a response from http://www.openembedded.org/project-overview , others also? Someone willing to fix it?
Oct 27 13:01:03 <CIA-31> 03tmbinc 07org.oe.dreambox * rf080e638... 10/ (1 packages/dreambox/dreambox-dvb-modules.bb): dreambox-dvb-modules: update dm500plus,dm600pvr to 20071026
Oct 27 13:27:11 <Jin^eLD> huhu
Oct 27 13:44:25 <chouimat> morning
Oct 27 14:27:03 <cdbot2> * * OE Bug 3217 has been created by arkangelgabriel(AT)gmail.com
Oct 27 14:27:05 <cdbot2> * * h2200 doesn't charge while suspended (angstrom)
Oct 27 14:27:07 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=3217
Oct 27 14:52:56 <slapin_nb> hi, all!
Oct 27 14:53:32 <slapin_nb> do anybody aware of a tool which could help build program tree regarding functions (tree of calls)?
Oct 27 15:02:19 <sirfred> Good afternoon
Oct 27 16:23:00 <Jin^eLD> mhm I always forget that... what packages provides ldd?
Oct 27 16:23:31 <Crofton|home> binutils?
Oct 27 16:23:56 <Jin^eLD> I'll try, thx
Oct 27 16:23:59 <Crofton|home> hmmm
Oct 27 16:24:07 <Crofton|home> maybe glibc?
Oct 27 16:24:12 <Crofton|home> [balister@localhost ~]$ rpm -qf /usr/bin/ldd
Oct 27 16:24:13 <Crofton|home> glibc-common-2.5-18.fc6
Oct 27 16:24:23 <Jin^eLD> on fc yes, but I think in OE that was not part of glibc
Oct 27 16:24:28 <Jin^eLD> I should have written this down
Oct 27 16:24:42 <Jin^eLD> I got that question answered once but somehow I forgot :(
Oct 27 16:25:07 <wisp_> morning all (adjust for time differences accordingly... )
Oct 27 16:25:31 <wisp_> Philippe - are you on currently?
Oct 27 16:26:05 <pH5> in oe it's package ldd, but it is built by the glibc recipe.
Oct 27 16:26:53 <Jin^eLD> thanks pH5
Oct 27 16:27:37 <wisp_> I reported bug 3194 (http://bugs.openembedded.org/show_bug.cgi?id=3194) about a week ago - and it was closed because it couldn't be reproduced.  I have since reproduced it on my system twice, including a clean build with an updated monotone yesterday
Oct 27 16:31:19 <wisp_> basic symptomatology is that packages are not building in the proper order - everything will build if I manually build some before others, and I am having trouble seeing how this could be due to a local configuration difference - anyone have any ideas? (gtk+ failed on missing xinerama, bitbake libxinerama fixed, gtk+ failed on missing xrandr, bitbake xrandr fixed, and finally, librsvg failed on libgsf, bitbake libgsf fixed and then gpe-
Oct 27 16:32:35 <wisp_> any ideas to further troubleshoot this would be appreciated - I can get a working build, so it isn't stopping me, but if it is a real bug, I'd like to do what I can to help solve it.  TIA
Oct 27 16:32:46 <Zero_Chaos> wisp_: when people close bugs normally they don't wipe their tmp dir :-( surprise.  You need ot figure out which packages must be "bitbake -c clean" to reproduce the bug, then you can have someone reproduce it.
Oct 27 16:33:22 <wisp_> Zero_Chaos - actually, Philippe said he did build on a clean tree
Oct 27 16:33:57 <wisp_> but that's a good point - I'll see if I can replicate it that way after my current build finishes
Oct 27 16:34:25 <wisp_> (I've wiped my tmp dir 3 times troubleshooting this.... yes - it takes days)
Oct 27 16:34:29 <Zero_Chaos> wisp_: hmm, if he built on a clean tree, I'm sure something must have been different.
Oct 27 16:34:58 <wisp_> that's what I thought too - but I dont understand how DEPENDS could be different...
Oct 27 16:35:13 <wisp_> and it seems like that must be where the problem is
Oct 27 16:35:23 <wisp_> (but I know very little, so that is an assumption)
Oct 27 16:35:59 <Zero_Chaos> depends can be VERY different if he had a different machine or distro set.
Oct 27 16:36:21 <Zero_Chaos> or built a different image before the one you had that failed, or really built anything out of your order
Oct 27 16:36:38 <wisp_> ah
Oct 27 16:36:40 <wisp_> ok
Oct 27 16:36:43 <wisp_> that makes sense
Oct 27 16:36:54 <wisp_> this was Angstrom 2007.1 for h2200
Oct 27 16:37:04 <wisp_> I don't know if I added that to the bug - my bad
Oct 27 16:37:10 <wisp_> brb
Oct 27 16:37:52 <Zero_Chaos> enjoy ;-)
Oct 27 16:39:06 <mwester> wisp_, Zero_Chaos: There are MANY missing dependencies in OE at present.  Even when building with a clean tmp, one can have different results if one has set the number of parallel bitbake operations and the number of parallel compiles differently in one's local.conf file.
Oct 27 16:40:24 <mwester> Just report the issue as a missing dependency in the bitbake recipe that failed, and identify the missing package.
Oct 27 16:41:15 <Zero_Chaos> mwester: yes he did that, but it was closed because it was not reproducable, so I was trying to help him put enough info to hopefully reproduce it.
Oct 27 16:49:20 <Philippe> hey all
Oct 27 16:49:47 <Philippe> hey wisp_ 
Oct 27 16:51:33 <Philippe> I also build angstrom 2007.1 and for h2200
Oct 27 16:56:12 <wisp_> hey Philippe
Oct 27 16:56:14 <wisp_> hmm
Oct 27 16:56:36 <Philippe> wisp_: that is why I said that my local.conf was almost identical to you
Oct 27 16:56:45 <wisp_> I'm confused then
Oct 27 16:56:57 <wisp_> and you built on a fresh tree too
Oct 27 16:57:18 <Philippe> yes.
Oct 27 16:57:22 <Philippe> rm -rf build
Oct 27 16:57:31 <Philippe> rm -rf build/tmp I mean
Oct 27 16:57:47 <Philippe> wisp_: I really have no clue why it does not work for you
Oct 27 16:58:19 <wisp_> ok, well I know how to work around it - certainly don't mean to beat it to death
Oct 27 16:58:20 <Philippe> wisp_: what distro do you use?
Oct 27 16:58:31 <wisp_> of linux (desktop)?
Oct 27 16:58:32 <Philippe> wisp_: I am on debian SID (unstable(
Oct 27 16:58:41 <wisp_> debian etch stable
Oct 27 16:59:23 <Philippe> wisp_: should be ok I think. Unless something weird is happening with python...
Oct 27 17:00:05 <wisp_> I tried setting assumed_provided += qeum (or whatever the setting were) - failed on locale generation - if I unset that assume provided qemu, then locales generated fine - I might be missing an addition lib for qemu though
Oct 27 17:00:14 <wisp_> i can check my python version if that helps
Oct 27 17:00:44 <wisp_> 2.4.4
Oct 27 17:01:59 <Philippe> hmm, 2.4.4-5 here.
Oct 27 17:02:41 <wisp_> how would a python version diff cause this?
Oct 27 17:03:33 <Philippe> well bitbake is written in python. Maybe something is slightly differently interpreted
Oct 27 17:03:49 <wisp_> yeah - could be
Oct 27 17:04:07 <wisp_> just seems that the depends syntax is fairly straightforward...
Oct 27 17:04:12 <Philippe> It could also be that the problem does not show for me since I always build with PARALLEL_MAKE = "-j 4"
Oct 27 17:04:15 <mwester-laptop> According to previous discussions here, the issue is that when bitbake builds the dependency tree, and comes up with a list of candidates that it *can* build, which order it builds that list is non-deterministic.
Oct 27 17:04:16 <Philippe> and BB_NUMBER_THREADS = "4"
Oct 27 17:05:07 <wisp_> oh - I think that could make a BIG difference
Oct 27 17:05:16 <mwester-laptop> So, theoretically, if one is missing dependencies, which one builds first might be dependent upon something  as silly as which recipe comes up first when the directory is read.
Oct 27 17:05:24 <mwester-laptop> (unsorted, of course)
Oct 27 17:05:25 <wisp_> you probably have built all the dependencies btw you get to the problem
Oct 27 17:05:55 <wisp_> (by the time), not btw^...
Oct 27 17:06:03 <Philippe> wisp_: got that :-)
Oct 27 17:06:08 <wisp_> L)
Oct 27 17:06:21 <wisp_> gah! I can't even type a smilie today!
Oct 27 17:06:21 <Philippe> wisp_: well it would be a waste to let my second cpu do nothing, so that is why I use that
Oct 27 17:06:27 <wisp_> true enough
Oct 27 17:07:27 <wisp_> so if I can figure out a bitbake -c clean order that breaks this, could somebody verify it that _doesn't_ do parallel builds? :)
Oct 27 17:07:54 <wisp_> I assume you can't build a full image in 4 1/2 hours without it....
Oct 27 17:09:18 <Philippe> wisp_: no. But soon I am off for dinner with a friend and probably some drinks. So I can start a non-parallel build and see what happened tomorrow morning
Oct 27 17:09:35 <wisp_> that would be great, if you don't mind
Oct 27 17:09:46 <wisp_> I'll experiment with this as soon as my build finishes (hopefully by the end of the day...) and try to put some more focused 'breaks' in the bug
Oct 27 17:10:04 <Philippe> wisp_: no prob. I'll check. As GPE dev it is important to me that builds work in OE.
Oct 27 17:10:18 <Philippe> however gtk+ breaking should have been noticed by other people before
Oct 27 17:10:37 <Philippe> Openmoko also builds with OE and uses GTK+ for example
Oct 27 17:10:40 <wisp_> i'm not sure how much people screw with their tree once it works :)
Oct 27 17:10:59 <wisp_> right - but a lot of them use the mokomake setup
Oct 27 17:11:10 <wisp_> and those that don't may have had an existing tree
Oct 27 17:11:28 <wisp_> or mokomakefile??^
Oct 27 17:11:43 <wisp_> I also could be totally wrong :|
Oct 27 17:12:33 <wisp_> anyway - thanks all for your input (mwester, Zero_Chaos, and Philippe) - much appreciated.  I'll report bakc when I have more info.
Oct 27 17:13:13 <wisp_> I'll keep my windows open and will review it when I am back, but will be gone for most of today - ttyl
Oct 27 17:16:04 <cdbot2> * * OE Bug 3218 has been created by joseph(AT)pfeifferfamily.net
Oct 27 17:16:06 <cdbot2> * * gcc-cross-initial_4.2.2 doesn't compile
Oct 27 17:16:08 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=3218
Oct 27 20:52:14 <likewise> gm
Oct 27 20:52:21 <Jin^eLD> hey likewise 
Oct 27 21:21:24 <rickhg12hs> What's the licensing for OE?  Can it be used in the next big thing with the developers making making a billion ruppees?
Oct 27 21:23:24 <Crofton> yes
Oct 27 21:24:20 <rickhg12hs> Hmmm.  Maybe critical mass is sleeping in another time zone?  8-)
Oct 27 21:24:28 <Crofton> and it is Saturday
Oct 27 21:24:33 <Crofton> many devs are in EU
Oct 27 21:24:43 <rickhg12hs> brb
Oct 27 21:26:56 <zecke> rickhg12hs: BitBake is GPLv2, the OE metadata (.bb, .inc, .bbclass) is MIT licensed. The patches we have are compatible with the software we build
Oct 27 21:27:06 <zecke> rickhg12hs: e.g. a patch to Linux is considered GPL(v2)
Oct 27 21:27:37 <Jin^eLD> zecke: btw, what about the .conf files?
Oct 27 21:27:47 <zecke> Jin^eLD:  ;)
Oct 27 21:27:51 <Jin^eLD> =)
Oct 27 21:28:07 <Jin^eLD> let's assume I base a rootfs for a commercial product on a tweaked angstrom
Oct 27 21:28:10 <zecke> Jin^eLD: I should have added \ldots
Oct 27 21:29:13 <Jin^eLD> :>
Oct 27 21:33:04 <rickhg12hs> zecke: Thx
Oct 27 21:34:31 <zecke> rickhg12hs: We encourage contributions and bugfixes
Oct 27 21:35:27 <rickhg12hs> zecke:  After my first billion, I'll send everybody a coupon for my product. ;-)
Oct 27 21:36:04 <Crofton> you can sponsor dinner at OEDEM :)
Oct 27 21:36:14 <zecke> rickhg12hs: obvisouly you still need to obey GPL/LGPL and other licenses forcing you to distribute source
Oct 27 21:36:28 <zecke> rickhg12hs: we have a bbclass to help you with that though
Oct 27 21:37:26 <rickhg12hs> hmmmmm.  might just be pomme frites and beer for that OEDEM meal then.  8-)
Oct 27 21:37:37 <Crofton> that would be FOSDEM :)
Oct 27 21:37:43 <Jin^eLD> zecke: what does this bb class do?
Oct 27 21:38:25 <zecke> Jin^eLD: the version marcin will merge from poky will do the following. With every recipe you build, it will put the sourcecode in a LICENSE_NAME/ directory
Oct 27 21:38:58 <Jin^eLD> by "put" you mean really copying the tar.* ?
Oct 27 21:39:19 <zecke> Jin^eLD: yes
Oct 27 21:39:26 <Jin^eLD> I'd rather suggest to create a symlink to the file in the source directory
Oct 27 21:39:48 <zecke> Jin^eLD: so you as a company/distribution can check the licenses you have to distribute
Oct 27 21:39:55 <zecke> Jin^eLD: propose that, I could be wrong with copying ;)
Oct 27 21:40:02 <Jin^eLD> :)
Oct 27 21:40:18 <Jin^eLD> but generally good idea
Oct 27 21:40:51 <Jin^eLD> so, the .conf's are MIT too?
Oct 27 21:41:45 <Jin^eLD> it's just that the question recently came to my mind
Oct 27 21:41:48 <zecke> everything but the patches
Oct 27 21:41:50 <Jin^eLD> about using the distros
Oct 27 21:42:07 <zecke> and everything that states otherwise (probably stuff in contrib)
Oct 27 21:43:44 <Jin^eLD> you know what else would be cool?
Oct 27 21:43:59 <Jin^eLD> to have a way to produce a copy of OE with only the stuff that was used for the particular rootfs/distro
Oct 27 21:44:32 <Jin^eLD> since it's not sufficient to provide the sources, the build env must be provided as well (for GPL at least, if I am not mistaken)
Oct 27 21:45:21 <Jin^eLD> would be nice to have a more or less automated way of doing this, and also making sure that only what was used is included
Oct 27 21:52:56 <likewise> Jin^eLD: If you start with a clean base dir and conf files, if you build a target, you have anything you need in downloads/, or not? (ONLY if you fixed the revisions you need on all packages)
Oct 27 21:53:22 <likewise> package up the org.oe.dev. checkout, bitbake, downloads, build/conf
Oct 27 21:53:46 <Jin^eLD> well, but that's what I mean - org.oe.dev contains thousands of packages
Oct 27 21:54:52 <Jin^eLD> I'd rather prepare a stripped down version that only contains the things that were actually used
Oct 27 21:55:14 <Jin^eLD> I think it's less confusing 
Oct 27 21:55:51 <Crofton> interesting, OH HQ is about 6 miles from where my mother grew up
Oct 27 21:56:15 <Jin^eLD> what is OH?
Oct 27 21:56:22 <Crofton> openedhand
Oct 27 22:05:18 <Jin^eLD> nite everyone
Oct 27 23:40:15 * davygravy is away: ...for a while...
Oct 27 23:55:22 <likewise> jeremy_laine: hi there
Oct 27 23:57:43 <jeremy_laine> likewise : hi!
Oct 27 23:58:03 <jeremy_laine> I saw a commit which addresses the lib/nof problem, very nice
Oct 27 23:59:13 <jeremy_laine> I hope to be able to provide a more useful kernel defconf for the mpc8323e-rdb soon, I think mtd partitions should be turned on for instance
Oct 28 00:02:12 <likewise> jeremy_laine: did you check the standard config for the board that comes with the kernekl?
Oct 28 00:02:37 <likewise> btw. the lib/nof fix is not mine. Let me check.
Oct 28 00:05:18 <likewise> Hmm, I think I liked disable-multilib better than this patch.
Oct 28 00:06:05 <likewise> assuming we always target a single machine with one toolchain, disabling multilib is ok.
Oct 28 00:06:44 <likewise> (1) Keeping multilib enabled and then (2) copying only one library set doesn't look good to me
Oct 28 00:08:31 <jeremy_laine> I agree, it hides the problem
Oct 28 00:08:55 <jeremy_laine> why don't we preserve the lib/nof structure?
Oct 28 00:10:04 <jeremy_laine> are there cases where you might share a toolchain across hard/soft float targets?
Oct 28 00:11:09 <jeremy_laine> likewise : what do you mean by the "standard config"? the current defconfig comes straight from linux 2.6.23's default for mpc8323e-rdb
Oct 28 00:12:01 <likewise> jeremy_laine: yes that's the one I mean. Isn't MTD parts support enabled in there?
Oct 28 00:12:13 <jeremy_laine> no
**** BEGIN LOGGING AT Sun Oct 28 02:46:32 2007
**** BEGIN LOGGING AT Sun Oct 28 02:52:55 2007
**** ENDING LOGGING AT Sun Oct 28 02:59:57 2007