**** BEGIN LOGGING AT Fri May 07 02:59:56 2010
May 07 05:25:02 <eFfeM_work> gm everyone
May 07 06:28:12 <khem> eFfeM_work: hi
May 07 06:28:22 <khem> did your eglibc woes end
May 07 06:36:13 <eFfeM_work> khem, not really, i checked out the version without your patch and it builds, the one with your patch does not as limits.h is missing; it does not seem to be installed by eglibc-initial
May 07 06:36:21 <aditya_111> man
May 07 06:36:24 <aditya_111> gumstix
May 07 06:36:28 <aditya_111> wifi
May 07 06:36:32 <aditya_111> awesome
May 07 06:38:37 <eFfeM_work> khem, copied the workdir for eglibc and eglibc-initial just before the patch, now going to try to build the head version again
May 07 06:40:12 <eFfeM_work> Tartarus: can you say a little more about your problems with eglibc and calamari?
May 07 07:02:46 <ao2> mmh, bitbake 1.10 needs python-2.6 now?
May 07 07:07:06 <ao2> ah ok, it was my clone in a bogus status, seems to work now
May 07 07:14:57 <ericben> hi
May 07 07:15:55 <ericben> patchwork seems to not get patches since 06/05
May 07 07:16:37 <khem> ericben: hmm interesting
May 07 07:17:22 <khem> ericben: let Crofton|work know
May 07 07:17:54 <JaMa> SHR patchwork also stopped working, but 2 weeks ago.. some not_so_good upgrade available to install?
May 07 07:17:56 <ericben> http://article.gmane.org/gmane.comp.handhelds.openembedded/32424 + http://article.gmane.org/gmane.comp.handhelds.openembedded/32418 + http://article.gmane.org/gmane.comp.handhelds.openembedded/32410 didn't reach patchwork
May 07 07:18:31 <ericben> also : http://article.gmane.org/gmane.comp.handhelds.openembedded/32397
May 07 07:19:32 <khem> JaMa: no idea about patchwork
May 07 07:19:47 <ericben> while I'm here : anywone to have a look at these patches which are fixing some small problems with modules and kernel bbclass ? : http://article.gmane.org/gmane.comp.handhelds.openembedded/32418 + http://patchwork.openembedded.org/patch/2014/ + http://patchwork.openembedded.org/patch/2012/
May 07 07:19:57 <khem> ericben: I also look at my mbox for patches so I will see if something I can review
May 07 07:28:03 <ericben> khem: OK thanks
May 07 07:32:00 <khem> eFfeM_work: you have to unstage gcc-cross gcc-cross-intermediate gcc-initial eglibc eglibc-initial before you could rebuild eglibc-initial again
May 07 07:32:07 <khem> eFfeM_work: did you follow these steps ?
May 07 07:33:24 <eFfeM_work> khem, no, i only did a bitbake -c clean eglibc eglibc-initial
May 07 07:34:16 <eFfeM_work> khem the weird thing is that it now builds (it is about to finish, but it got beyond the configure pass that bailed out before
May 07 07:35:15 <khem> hmm
May 07 07:35:16 <eFfeM_work> khem: I did not do anything with gcc* but I didn't do that yesterday either
May 07 07:35:35 <khem> eFfeM_work: gcc and glibc has a weird catch-22
May 07 07:35:43 <khem> and bitbake/opkg does not help the cause
May 07 07:36:04 <khem> because intermediate packages overwrite real packages
May 07 07:36:23 <khem> when you unstage one the other gets unstaged too but bitbake does not know about it
May 07 07:37:02 <khem> ideally it should unstage and mark all conflicting packages unstaged
May 07 07:37:05 <eFfeM_work> khem should there be additonal deps for it
May 07 07:37:14 <khem> no deps can help
May 07 07:37:25 <khem> its the bootstrap
May 07 07:37:46 <khem> only if we staged the intermediate stuff separately then it would help
May 07 07:38:36 <eFfeM_work> anyway my issue was that include-fixed/limits.h included limits.h which was not there
May 07 07:39:04 <eFfeM_work> guess a full rebuild would have also fixed thigns
May 07 07:40:46 <khem> yeah and this file limits.h comes from eglibc-inital
May 07 07:40:56 <khem> so here was the catch-22 you were in
May 07 07:41:14 <khem> you had a gcc which wanted that file installed
May 07 07:41:22 <khem> but it would be installed after you build the package
May 07 07:41:36 <eFfeM_work> khem, yeah found that from looking at the work dir for an older version, it was not installed after I pulled your version, but now it is
May 07 07:42:29 <eFfeM_work> khem, not really; eglibc-initial build fine, it was in eglibc configure where it failed; could be a task ordering issue that eglibc-initial install was not completed yet when egblic configure runs
May 07 07:43:10 * eFfeM_work is checking the console history
May 07 07:47:05 <khem> ok
May 07 07:49:04 <eFfeM_work> can't see anything in the history that indicates a problem, guess the problem is gone for me, I'll rm tmp and do a clean rebuild over the weekend
May 07 07:50:23 <khem> ok even better
May 07 07:54:02 <eFfeM_work> khem will let you know if new issues crop up, but guess it is resolved, tnx alot
May 07 07:54:28 <eFfeM_work> note to self: standard solution to OE build problems is restart with a clean slate
May 07 07:54:39 <eFfeM_work> restart == rebuild
May 07 07:55:14 <khem> not always but sometimes when there are disruptive changes 
May 07 07:55:32 <CIA-2> 03Michael Lippautz <michael.lippautz@gmail.com> 07org.openembedded.dev * r18b3318aa5 10openembedded.git/recipes/libpcre/libpcre_7.6.bb: libpcre: Remove old staging
May 07 07:56:31 <ao2> building meta-toolchain with DISTERO=minimal MACHINE=a780: ERROR: '['/home/ao2/Proj/EZX/OE/openembedded/recipes/tasks/task-sdk-host.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'gdb-cross-sdk' but it wasn't found in any PACKAGE or RPROVIDES variables
May 07 07:56:32 <ao2> ERROR: Required build target 'meta-toolchain' has no buildable providers.
May 07 07:56:32 <ao2> Missing or unbuildable dependency chain was: ['meta-toolchain', 'task-sdk-host', 'gdb-cross-sdk']
May 07 07:58:55 <ao2> gdb-cross-sdk is in RDEPENDS for 'task-sdk-host'
May 07 08:02:40 <khem> ao2: how old is your snapshot
May 07 08:03:24 <ao2> half an hour?
May 07 08:04:13 <khem> hmm
May 07 08:04:16 <ao2> pulled org.openembedded.dev this morning and cleaned build/tmp/
May 07 08:04:39 <khem> ao2: can you do bitbake -g meta-toolchain and port the .dot files somehwere
May 07 08:04:47 <ao2> sure
May 07 08:11:43 <ao2> khem, the dot fine is not genrated, bitbake bails out with the same message, here's the full one: http://pastebin.com/6jVHLddr bitbake 1.10
May 07 08:11:49 <ao2> s/fine/file/
May 07 08:14:37 <khem> ao2: try passing -DDD
May 07 08:14:46 <khem> to bit bake and log the output
May 07 08:14:59 <ao2> khem, will do
May 07 08:16:00 <khem> ao2: btw. do you have gdb-cross-sdk recipes in recipes/gdb ?
May 07 08:18:21 <ao2> khem, I do, latest is recipes/gdb/gdb-cross-sdk_7.1.bb
May 07 08:18:58 <ant_work> morning
May 07 08:19:00 <khem> ao2: np I can reproduce it
May 07 08:19:18 <ao2> khem, ok
May 07 08:19:44 * ant_work hopes he's waking up from the nightmare of yesterday...all sort of issues alltogether :/
May 07 08:20:00 <khem> ant_work: life is better
May 07 08:20:13 <khem> I have booted two arches with latest stuff
May 07 08:20:44 <ant_work> most remarkablekhem: best one was
May 07 08:20:46 <ant_work> NOTE: package gcc-cross-intermediate-4.3.3-r11.1: task do_populate_sysroot: Started
May 07 08:20:53 <ant_work> new rpath '$ORIGIN/../../../../usr/lib:$ORIGIN/../../../../../..' too large; maximum length 50
May 07 08:23:06 <khem> chug along 
May 07 08:23:13 <khem> thats just a note ant_work 
May 07 08:23:32 <ant_work> yea, but was the rpath changed otr not?
May 07 08:25:57 <ant_work> and  bitbake package-index did not end...
May 07 08:27:55 <ant_work> anyway, is friday ;)
May 07 08:36:57 <khem> yes
May 07 09:02:08 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r504e77420b 10openembedded.git/ (2 files in 2 dirs): linux-omap-psp 2.6.32: move to 3.00.01.06
May 07 09:55:05 <florian> good morning
May 07 09:55:11 <florian> hrw|gone: ping
May 07 10:07:02 <hrw> pong florian 
May 07 10:09:11 <florian> hrw: Do you think the "umask 000" in the buildbot scripts is a good idea? Is there a reason not to use e.g. 022
May 07 10:10:34 <hrw> florian: I had that in my scripts mostly to be able to go into buildbot dirs as not-buildbot user
May 07 10:11:26 <CIA-2> 03Roger Monk <r-monk@ti.com> 07org.openembedded.dev * r75d45d51e8 10openembedded.git/recipes/ti/ti-cgt6x_6.1.14.bb: 
May 07 10:11:26 <CIA-2> ti-cgt6x: Add version 6.1.14
May 07 10:11:26 <CIA-2> Signed-off-by: Roger Monk <r-monk@ti.com>
May 07 10:11:26 <CIA-2> Signed-off-by: Koen Kooi <k-kooi@ti.com>
May 07 10:12:24 <florian> hrw: The drawback is that this influences everything... in a way that might be very unpleasant.
May 07 10:13:03 <hrw> florian: basically do not alter umask
May 07 10:14:40 <florian> hrw: it might be necessary since buildbot alters it if i remember correctly.
May 07 10:23:50 <ant_work> hrw: you once discouraged against piping the output of bitbake on a file...better ideas to keep the full log (with NOTES)?
May 07 10:26:50 <ant_work> tee?
May 07 10:27:34 <JaMa> me always use tee
May 07 10:27:43 <JaMa> and really long screen history
May 07 10:28:16 <ant_work> ok, thx
May 07 10:28:34 <CIA-2> 03Jacob Helwig <jacob@technosorcery.net> 07org.openembedded.dev * r23ebefbac8 10openembedded.git/docs/usermanual/reference/var_src_uri.xml: 
May 07 10:28:34 <CIA-2> usermanual: Add missing opening <varlistentry> tag in the user manual.
May 07 10:28:34 <CIA-2> While we're here, remove the straggling hard-tabs.
May 07 10:28:34 <CIA-2> Signed-off-by: Jacob Helwig <jacob@technosorcery.net>
May 07 10:29:04 <JaMa> with 1.10 it's great to see error log (ie log.do_compile) immediately on bitbake output, but for longer logs it's harder to find log filename, would be great to say filename in the begining as well as after log
May 07 10:29:53 <hrw> ant_work: use screen logging function
May 07 10:29:57 <ant_work> I had silent (no logs in workdir) failure building console-image
May 07 10:30:00 <ant_work> JaMa: btw could you pls try 'bitbake package-index' ?
May 07 10:30:02 <hrw> ant_work: best way for logs
May 07 10:30:54 <JaMa> ant_work: I use -c rebuild -b path_to_package-index
May 07 10:31:09 <JaMa> ant_work: but i guess both works
May 07 10:32:19 <ant_work> this simple package was failing/stalling on task do_setscene
May 07 10:32:46 <JaMa> ant_work: have you tried to -c clean it first?
May 07 10:32:58 <ant_work> it was a rebuild from scratch
May 07 10:33:08 <JaMa> seen that too on another host, but -c clean and it worked ok again
May 07 10:34:42 <ant_work> bah..I had all sort of issues that I zapped tmpdir and went away..
May 07 10:35:18 <ant_work> further rebuils were triggering new oddities..
May 07 10:35:20 <ant_work> 	 cp: cannot stat `/oe/build/tmp/work/i686-linux/stagemanager-native-0.0.1-r12/sysroot-destdir//oe/build/tmp/*': No such file or directory
May 07 10:36:08 <ant_work> I fit rehappens today I'll send a msg to the ML
May 07 10:36:34 <ant_work> I kept part of the screen logs
May 07 10:37:25 <GNUtoo> hi, I bitbaken wesnoth with boost 1.41,then cleaned both and bitbaken gnash and wesnoth with boost 1.40,it didn't create 1.40 packages,how do I create them and install them?
May 07 10:47:25 <Crofton|work> mickey|sports, ping
May 07 10:53:51 <hrw> XorA: alive?
May 07 10:55:34 <XorA> hrw: yes
May 07 10:55:42 <Crofton|work> he seems depressed over the election
May 07 10:56:02 <XorA> Crofton|work: I dont care really, its a bunch of idiots no matter who won
May 07 10:56:03 <woglinde> ???
May 07 10:56:14 <Crofton|work> :)
May 07 10:56:17 <hrw> XorA: when you arrive at uds?
May 07 10:56:23 <hrw> woglinde: UK election
May 07 10:56:24 <woglinde> hm the ti stuff works with binutils 2.18
May 07 10:56:34 <woglinde> hrw not better than here
May 07 10:56:44 <zecke> XorA: ah, you are with Canonical too?
May 07 10:56:56 <woglinde> he zecke
May 07 10:57:00 <woglinde> hr mickyl
May 07 10:57:02 <Crofton|work> damn it, we have the worst politicians!
May 07 10:57:20 <XorA> zecke: I work for LRG
May 07 10:57:23 <Crofton|work> zecke, we need that gsm monitoring solution :)
May 07 10:57:34 <XorA> zecke: just happen to be doing some work on Ubuntu stuff
May 07 10:57:40 <XorA> hrw: monday night
May 07 10:58:23 <woglinde> crofton in th US?
May 07 10:58:29 <Crofton|work> yes
May 07 10:58:52 <Crofton|work> we are the best at everything, including having the worst politicians :)
May 07 10:59:06 <zecke> Crofton|work: well, you should buy an operator
May 07 10:59:09 * XorA can guarantee two things, more taxes and more anti terror laws
May 07 10:59:39 <Crofton|work> based on recent events, the terrorists are gettting stupid
May 07 10:59:43 <hrw> XorA: still +4477xxxxxx58 is your phone number?
May 07 10:59:54 <XorA> hrw: yes
May 07 11:00:30 <hrw> XorA: I have same as in past too
May 07 11:00:37 <XorA> hrw: +4860xxxxxx708?
May 07 11:00:45 <hrw> yes
May 07 11:00:50 <XorA> awesome
May 07 11:01:45 <broonie> XorA: Hrm, that's a point - I'll just text you my owrk mobile number in case I do make it to UDS (someone else pays the roaming fees for it!)
May 07 11:01:47 <XorA> land at 7pm local time, so I guess Ill be at hotal about 8pm
May 07 11:02:25 <hrw> broonie: we need to make a beer then
May 07 11:02:28 <XorA> broonie: got it
May 07 11:02:49 <hrw> http://lists.impactlinux.com/pipermail/firmware-impactlinux.com/2009-November/000468.html
May 07 11:03:03 <broonie> hrw: Yup
May 07 11:12:07 <RP> ant_work: If you're having problems, I really need detailed reports to the OE mailing list rather than cryptic fragments on irc:)
May 07 11:17:57 <ant_work> sure
May 07 11:18:25 <ant_work> I'll log the screen this time
May 07 11:23:01 <tasslehoff> I'm creating a recipe for apiextractor, which uses cmake to build. During configure it complains about not finding qmake. How do I fix this?
May 07 11:24:39 <ant_work> as woglinde saw, there are a couple of packages wich are suggested to inherit gettext (one is coreutils-native). Quilt native has strangeness too
May 07 11:24:49 <Crofton|work> zecke, I need to work hard on openbts codebase :)
May 07 11:29:53 <hrw> ok, bye all
May 07 11:33:37 <woglinde> re
May 07 11:35:11 <tasslehoff> anyone? I tried to do "export QMAKE" like the konqueror-recipe does, but to no avail.
May 07 11:39:18 <tasslehoff> bah, depending on qmake-native will probably help :)
May 07 11:40:51 <tasslehoff> or not
May 07 12:06:56 <zecke> Crofton|work: want? or you can?
May 07 12:07:13 <Crofton|work> want at the moment
May 07 12:07:20 <Crofton|work> busy on a nother project
May 07 12:07:47 <Crofton|work> ttsou has been using openbts to help teach people about cellular systems
May 07 12:09:59 <zecke> yeah, I learn alot about celluar systems...
May 07 12:10:13 <zecke> like how to handle people coming out of an airplane (or a comparable flood)
May 07 12:10:59 <Crofton|work> heh
May 07 12:11:11 <Crofton|work> that must be crazy all those phones coming on at once
May 07 12:12:04 <zecke> Crofton|work: yeah, and to make it worse the network tries to deliver the welcome SMS as well.
May 07 12:12:24 <Crofton|work> I haven't seen that in the US lately
May 07 12:13:21 <zecke> Crofton|work: I assume you roam less lately
May 07 12:13:39 <Crofton|work> not really
May 07 12:14:02 <Crofton|work> although travel within us I don't "roam"
May 07 12:14:06 <ant_work> zecke: can these broadcast operator-welcome be filtered on normal phones (symbian?)
May 07 12:14:13 <Crofton|work> I was in California for a couple of weeks
May 07 12:14:19 <XorA> those SMS drive me crazy
May 07 12:14:23 <ant_work> yep
May 07 12:14:32 <XorA> I dont want told 10 times that Im in another country
May 07 12:14:41 <ant_work> when I travel from IT through CH to DE...10-12 msgs
May 07 12:14:43 <XorA> I just got off a plan goddamit, I better be somewhere else
May 07 12:15:02 <ant_work> not only in airport
May 07 12:15:09 <woglinde> ant thats eu-law
May 07 12:15:14 <XorA> even worse when they used to come in the local language
May 07 12:15:24 <zecke> ant_work: how should I know?
May 07 12:15:42 <ant_work> I never messe with phones
May 07 12:16:32 <ant_work> but if those are broadcast msgs it can be funny without a 'firewall'
May 07 12:16:35 <soltys> any one with buildhost on freebsd ?
May 07 12:18:20 <ant_work> woglinde: iirc there should be a new law wrt roaming costs
May 07 12:18:24 <ant_work> in EU
May 07 12:18:45 <woglinde> ant hm not real law
May 07 12:18:58 <ant_work> nowI mean a Directive/Verordnung
May 07 12:19:31 <woglinde> but upper limit
May 07 12:19:36 <ant_work> he he
May 07 12:19:36 <woglinde> for roaming cost
May 07 12:20:04 <ant_work> we'll see, now it is very expensive
May 07 12:20:18 <ant_work> without any real reason but profit
May 07 12:20:35 <ant_work> is like with the banks before IBAN
May 07 12:20:37 <Crofton|work> Greed is Good!
May 07 12:21:33 <ant_work> people must earn to be able to spend
May 07 12:21:44 <ant_work> that's how it worls
May 07 12:22:20 <Crofton|work> that's a line from the movie wall street
May 07 12:23:04 <woglinde> hm something in the deps of gtk-native is broken
May 07 12:23:19 <zecke> ant_work: no, it is not broadcast.
May 07 12:23:19 <woglinde> pulls in a lot of none native packages
May 07 12:23:24 <ant_work> woglinde: did you see that gettext msgs in coreutils-native?
May 07 12:23:49 <woglinde> ant yes
May 07 12:24:09 <ant_work> there was another one later in the logs..I'll keep track this time
May 07 12:24:18 <ant_work> and quilt too
May 07 12:24:26 <ant_work> was complaining 
May 07 12:24:27 <woglinde> ant yes
May 07 12:24:43 <ant_work> ok, is not only by me :)
May 07 12:24:54 <ant_work> parallel build? bbthreads?
May 07 12:25:26 <woglinde> ant has nothing to do with bbthreads
May 07 12:25:38 <ant_work> I suspect I hit some race 
May 07 12:25:42 <woglinde> its a warning rp build in
May 07 12:25:44 <ant_work> no, other issues :/
May 07 12:25:56 <woglinde> someone should fix it
May 07 12:26:00 <mickey|office> morning
May 07 12:26:10 <woglinde> quilt shoud be converted to BBCLASSEXTEND to
May 07 12:26:24 <woglinde> hm
May 07 12:26:34 <woglinde> gtk+-native has pango as dep
May 07 12:26:37 <woglinde> how odd
May 07 12:27:07 <ant_work> woglinde: some packages were stalling on task do_setscene apparently
May 07 12:29:46 <woglinde> got it
May 07 12:29:46 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc302f739d4 10openembedded.git/recipes/git/git_1.7.0.2.bb: git: add ssh to recommends
May 07 12:29:48 <woglinde> "pango-native.do_package_write_ipk" -> "pango.do_package"
May 07 12:35:20 <woglinde> hm pango.inc has old staging
May 07 12:35:35 <woglinde> maybee thats the problem
May 07 12:36:25 <woglinde> hm nope
May 07 12:49:23 <woglinde> hm hm
May 07 12:49:26 <woglinde> ping rp
May 07 12:54:17 <woglinde> ping kergoth
May 07 12:54:19 <woglinde> hm
May 07 13:37:36 <soltys> any one with buildhost on freebsd ?
May 07 13:41:52 <ant_work> no..sorry
May 07 13:42:15 <ant_work> perhaps Jay7 had some bsd
May 07 13:43:29 <soltys> thats bad..
May 07 13:43:39 <soltys> maybe on ml there will be some..
May 07 14:13:38 <mwester> gm
May 07 14:57:01 <mouss> hello
May 07 14:57:29 <mouss> i need a support to use an angstrom base distribution with an external toolchain
May 07 14:57:47 <rhc> mouss: i'm doing the same thing, what's your question?
May 07 14:57:50 <mouss> this toolchain has been build using the recipe meta-toolchain.bb
May 07 14:58:15 <mouss> then i have untarred the 2 tar.gz produced to /
May 07 14:58:53 <mouss> so i have the /usr/local/angstrom/ directories
May 07 14:59:33 <mouss> then i have change my distro.conf file with the following :
May 07 14:59:33 <mouss> TOOLCHAIN_TYPE ?= "external"
May 07 14:59:33 <mouss> TOOLCHAIN_BRAND ?= "generic"
May 07 15:00:30 <mouss> but at the end , when i reach the point to create my filesystem image ihave the following error :
May 07 15:00:30 <mouss> Configuring kernel-2.6.32.
May 07 15:00:30 <mouss> | Configuring update-rc.d.
May 07 15:00:30 <mouss> | Configuring busybox.
May 07 15:00:30 <mouss> | Configuring enove-appli.
May 07 15:01:15 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r6267e295d4 10openembedded.git/recipes/perl/ (perl-native_5.10.1.bb perl-native_5.8.8.bb): 
May 07 15:01:15 <CIA-2> perl-native: fix do_install a bit more
May 07 15:01:16 <CIA-2> * this doesn't solve the build problem with perl, though
May 07 15:01:16 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * raa5af845e4 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorted: add imote2 support
May 07 15:01:53 <mouss> hello i am here again
May 07 15:01:59 <mouss> sorry about the excess fllod
May 07 15:02:01 <mouss> flood
May 07 15:02:05 <mouss> i did not know
May 07 15:02:11 <mouss> did you get my problem ?
May 07 15:02:37 <mouss> the error i had is the following :
May 07 15:02:37 <mouss> satisfy_dependencies_for: Cannot satisfy the following dependencies for task-boot:
May 07 15:02:37 <mouss> |  *    glibc *         glibc *         glibc *         glibc *         glibc *
May 07 15:02:45 <mwester> pastebin, mouss
May 07 15:02:54 <mouss> ah ok right
May 07 15:04:13 <mouss> http://pastebin.com/mhkDhuK1
May 07 15:09:22 <JaMa> Steffen Sledz here?
May 07 15:12:31 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rfe4ff6940b 10openembedded.git/recipes/perl/ (perl_5.10.1.bb perl_5.8.8.bb): perl: change 'cp' to 'ln' to fix perl build issues, thanks to Tom Rini for the suggestion
May 07 15:15:06 <mouss> mwester, have you encounter this problem ?
May 07 15:16:19 <mwester> no.  Actually, the distro I'm responsible for hasn't built since someone checked in a broken change two weeks ago, so I'm not able to see what problems currently exist.
May 07 15:18:25 <mouss> what is that distro ?
May 07 15:21:54 <mwester> One of the older distro's in OE - SlugOS
May 07 15:40:57 <ant_work> mwester: you had opkg-cl waiting for input iirc. What was exactly?
May 07 15:41:47 <XorA> we realy should make our opkg-native fail under those conditions
May 07 15:42:05 <ant_work> I suppose SlugOS could miss some magic bit present in A. and minimal
May 07 15:42:29 * XorA hopes Angstrom isnt silently ignoring file overwrites
May 07 15:42:48 <XorA> there is a always answer Y command line to opkg so its possible I guess
May 07 15:43:11 <ant_work> there was an issue months ago, got solved iirc
May 07 15:43:28 <ant_work> at least, I did not see it anymore
May 07 15:43:50 <ant_work> must be in the ML
May 07 15:44:52 <mwester> ant_work,  a recent OE change added /etc/device_table to the CONFFILES, so when opkg was building the rootfs, and installed the package that contains the REAL /etc/device_table, it sat there consuming 100% of a processor asking if it should overwrite /etc/device_table or not.
May 07 15:45:19 <mwester> XorA is right that it should fail rather than hang.
May 07 15:45:20 <ant_work> ah..CONFFILES 
May 07 15:45:24 <robtow> yikes
May 07 15:45:55 <ant_work> this is debian/U-A biased..I don't know exactly
May 07 15:46:07 <ant_work> (portage rulez)
May 07 15:46:07 <mwester> But it would be nice if someone could also offer a suggestion on how to handle such cases.  How do I remove the unwanted /etc/device_table that apparently I now get courtesy of somebody else?
May 07 15:46:30 <ant_work> he
May 07 15:47:34 <mwester> (And yes it would ideal if I would find some way to integrate SlugOS' handling of the device_table into whatever the new mechanism is, because I suspect that SlugOS has its own due to the very bug that commit fixed... but that takes time I do not have, and each day that passes means more testing has been missed...)
May 07 15:48:23 <XorA> that commit just looks wrong, and it looks to me like we have always done them wrong
May 07 15:48:29 * XorA never looked at the area before
May 07 15:48:39 <XorA> rm -rf ${IMAGE_ROOTFS}/etc/device_table
May 07 15:49:04 <mwester> yes, but where?
May 07 15:49:29 <XorA> mwester: I mean removing the package supplied dev_table feels really wrong to me
May 07 15:50:02 <XorA> mwester: image.bbclass is poking around in files marked as owned by packages, thats just nasty
May 07 15:50:28 <mwester> Ah.  Yes.  But I did spend some time investigating this a year ago, when I ported SlugOS to the Sheevaplug and needed a different device_table.  There's no doubt that the way SlugOS does it is not right either.
May 07 15:50:54 <mwester> I'm not sure WHO should really own files like device_table.
May 07 15:50:55 <woglinde> soltys please look at openembedded/site and put a file for your bsd there
May 07 15:52:49 * XorA doesnt see why this cannot be done in a dev-tables.bb which is PACKAGE_ARCH = "${MACHINE_ARCH}"
May 07 15:52:50 <mwester> But I guess I do feel that there is an argument to be made that the device_table created by OE from the files in the ${OE}/conf directory should probably be able to be overwritten by one provided as part of a bb recipe directly.
May 07 15:52:55 <XorA> but I dont have time to work on it
May 07 15:53:20 <XorA> whole thing does feel wrong to me
May 07 15:53:22 <Tartarus> mwester: So, if I follow this right, SlugOS has had a /etc/device_tables file for a long time, right?
May 07 15:53:38 <mwester> Hmmm... a specific bb for the device_table?  That actually sounds rather heavy-wieght, but it should work.
May 07 15:53:41 <mwester> Tartarus,  yes.
May 07 15:53:50 <Tartarus> mwester: What's the hook you made to do it?
May 07 15:53:54 <ant_work> in slugos-image.inc
May 07 15:53:55 <ant_work> IMAGE_DEVICE_TABLES = "files/device_table-slugos.txt"
May 07 15:54:03 <XorA> mwester: I dont think there should be any files on rootfs not owned by a package
May 07 15:54:08 <soltys> woglinde: no idea what to put in it..
May 07 15:54:19 <mwester> Tartarus,  it's added by the SlugOS-specific initscripts.
May 07 15:54:20 <soltys> woglinde: I'm new to this
May 07 15:54:37 <Tartarus> mwester: OK, I think the answer is to switch to what ant_work just said
May 07 15:54:51 <Tartarus> XorA: I know a lotta folks who think just the opposite
May 07 15:55:09 <mwester> ant_work,  I messed with that during the Sheevaplug porting; I can't recall what broke but it broke badly when I changed that.
May 07 15:55:09 <XorA> Tartarus: then they are plain wrong :-D
May 07 15:55:18 <Tartarus> XorA: Doubly so if you're expecting to be able to use OE to create the image you need now, not to have to customize it later
May 07 15:55:55 <XorA> Tartarus: thats just bad engineering, these sort of hacks always end up deployed
May 07 15:56:11 <ant_work> iirc IMAGE_DEVICE_TABLES != IMAGE_DEVICE_TABLE
May 07 15:56:24 <ant_work> I can't grep from here...
May 07 15:56:38 <XorA> hmm, looks like package staging is up the wazoo :-(
May 07 15:56:54 <Tartarus> XorA: If they're written in recipes, they aren't so much hacks as working around other peoples designs
May 07 15:59:01 <mwester> ant_work,  that's correct - the plural form and the singular are different, and IIRC I can override one but not the other... which is what messed up the Sheevaplug variation for SlugOS...
May 07 15:59:10 <ant_work> OMG
May 07 15:59:17 <woglinde> soltys run configure manualy
May 07 15:59:28 <woglinde> soltys and fetch the stuff from there
May 07 15:59:40 <soltys> woglinde: but it fail while parsing recipes
May 07 15:59:51 <woglinde> than put the stuff into file called i386-freebsd8
May 07 16:21:35 <CIA-2> 03Eric Benard <eric@eukrea.com> 07org.openembedded.dev * r8f712018ec 10openembedded.git/classes/kernel.bbclass: (log message trimmed)
May 07 16:21:36 <CIA-2> kernel.bbclass: fix staging of .config
May 07 16:21:36 <CIA-2> - in staging.bb : sysroot_stage_dir does : cp -fpPR "$src"/* "$dest"
May 07 16:21:36 <CIA-2> which means it won't copy .config
May 07 16:21:36 <CIA-2> - so do the copy of .config in sysroot_stage_all_append after
May 07 16:21:36 <CIA-2> sysroot_stage_dir
May 07 16:21:36 <CIA-2> Signed-off-by: Eric Benard <eric@eukrea.com>
May 07 16:38:57 <woglinde> hi steliosk
May 07 16:40:30 <steliosk> wongline : hi !
May 07 17:02:58 <woglinde> re kergoth
May 07 17:03:05 <kergoth_> hey
May 07 17:03:07 <kergoth_> how's it going?
May 07 17:03:20 <woglinde> kergoth I have a nice problem for you or rp
May 07 17:03:27 <kergoth_> okay, what is it?
May 07 17:03:34 <woglinde> its regarding native packages
May 07 17:03:45 <woglinde> try bitbake -g gtk+-native
May 07 17:03:50 <woglinde> and look the depends
May 07 17:04:15 <woglinde> I am not sure that only packages with BBCLASSEXTEND are in case
May 07 17:05:09 <woglinde> but for example when a native package has a dependency on another native package
May 07 17:05:18 <woglinde> which uses BBCLASSEXTEND
May 07 17:05:45 <woglinde> the do_stage from the not-native package of the recipe is dragged in
May 07 17:05:54 <woglinde> and there for the whole crosscompiling
May 07 17:06:21 <kergoth_> hmm
May 07 17:06:40 <woglinde> it isn't a show stopper
May 07 17:07:25 <kergoth_> interesting.
May 07 17:07:45 <kergoth_> bitbake gtk+-native builds gcc-cross and everything, that's the issue?
May 07 17:07:47 <kergoth_> weird.
May 07 17:07:56 <woglinde> the reason is
May 07 17:08:00 <woglinde> pango
May 07 17:08:02 <woglinde> or atk
May 07 17:08:41 <woglinde> gtk+-native do_ipkg depends on pango-native.do_stage and pango.do_stage
May 07 17:08:48 <woglinde> the rest you can imagine
May 07 17:09:56 <woglinde> I am not sure if the problem comes from bitbake or oe
May 07 17:12:10 * kergoth_ nods
May 07 17:12:35 <kergoth_> will look into it
May 07 17:12:41 <woglinde> :)
May 07 17:25:50 <kergoth_> hmm
May 07 17:25:54 <kergoth_> i should look at the runqueue generation code
May 07 17:35:56 <kergoth_> why do i have stephen lynch - grandfather stuck in my head?
May 07 17:41:13 <kergoth_> yow. someone at work determined that the uname call in BUILD_OS is executed like 47,000 times in a typical build.. time for a ;=
May 07 17:41:18 <kergoth_> s/;=/:=/
May 07 17:53:10 <kergoth_> hmm
May 07 17:53:29 <kergoth_> I think if I can fix this pysh problem with case statements, I may be ready to start looking at the BitBake integration
May 07 17:53:30 <CIA-2> 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r4300942c87 10openembedded.git/recipes/net-snmp/net-snmp.inc: 
May 07 17:53:30 <CIA-2> net-snmp: fix static libs packaging
May 07 17:53:30 <CIA-2> No reason to have static libraries in -libs package.
May 07 17:53:30 <CIA-2> Signed-off-by: Roman I Khimov <khimov@altell.ru>
May 07 17:53:40 <CIA-2> 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r34f01346be 10openembedded.git/recipes/net-snmp/net-snmp.inc: 
May 07 17:53:40 <CIA-2> net-snmp: convert to new staging
May 07 17:53:40 <CIA-2> Signed-off-by: Roman I Khimov <khimov@altell.ru>
May 07 17:55:09 <CIA-2> 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r25fc39e389 10openembedded.git/recipes/pacemaker/ (files/kill-stack-protector.patch pacemaker_1.0.8.bb): 
May 07 17:55:10 <CIA-2> pacemaker: completely disable stack protector for uclibc builds
May 07 17:55:10 <CIA-2> Make uclibc builds stable across different architectures.
May 07 17:55:10 <CIA-2> Signed-off-by: Roman I Khimov <khimov@altell.ru>
May 07 18:16:56 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r9dd31c31a3 10openembedded.git/conf/machine/include/omap3.inc: omap3.inc: bump MACHINE_KERNEL_PR
May 07 18:27:43 <cbrake> hmm, Ubuntu 10.04 can't untar expat-2.0.1.tar.gz - works fine on 9.10 ...
May 07 18:28:00 <kergoth_> ouch
May 07 18:28:12 <cbrake> gzip: stdin: invalid compressed data--crc error
May 07 18:28:27 <khem> cbrake: always the case ?
May 07 18:28:31 <cbrake> md5sum looks fine
May 07 18:28:33 <cbrake> khem: yes
May 07 18:28:45 <cbrake> khem: do you have 10.04 running on anything handy?
May 07 18:28:50 <kergoth_> maybe the issue was always there and the new one is just more picky?
May 07 18:29:02 * kergoth_ has a 10.04 upgrade going as we speak, but thats got another 1.5 hours to go :)
May 07 18:29:08 <cbrake> kergoth_: yeah, seems likely
May 07 18:29:24 <cbrake> anyone have Ubuntu 10.04 and care to try to untar: http://downloads.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz?use_mirror=softlayer
May 07 18:29:35 <kergoth_> wonder if there's an option to make it continue anyway, or repair it, or something
May 07 18:32:06 <cbrake> I'd like to verify at least one other person is seeing it
May 07 18:32:21 * kergoth_ nods
May 07 18:32:43 <kergoth_> anyone here decent with python and want to review some code for me?
May 07 18:33:18 <woglinde> hm
May 07 18:33:23 <woglinde> I can look over it
May 07 18:33:41 <woglinde> but dont know if I can spot something
May 07 18:34:15 <woglinde> so lets give it a try
May 07 18:36:58 <khem> cbrake: yes I have 10.04 on two systems
May 07 18:37:32 <cbrake> khem: do you mind trying to unzip expat-2.0.1.tar.gz?
May 07 18:37:37 <khem> trying
May 07 18:38:13 <khem> cbrake: works
May 07 18:38:18 <khem> tar -xzf expat-2.0.1.tar.gz
May 07 18:38:44 <woglinde> kergoth where is the code?
May 07 18:38:46 <woglinde> hi khem
May 07 18:38:50 <cbrake> khem: maybe this is a sign I should take the rest of the afternoon off :-\
May 07 18:38:57 <woglinde> khem with binutils 2.18 the ti stuff builds
May 07 18:39:05 <cbrake> khem: I'll try rebooting ...
May 07 18:39:16 <cbrake> khem: thanks
May 07 18:39:24 <khem> woglinde: hmm interesting
May 07 18:39:44 <khem> woglinde: you need to enable me to reproduce it 
May 07 18:39:50 <khem> cbrake: ok
May 07 18:39:56 * khem out to lunch 
May 07 18:40:21 <woglinde> khem sure
May 07 18:40:25 <woglinde> uise angstorem
May 07 18:40:29 <woglinde> binutils 2.19.1
May 07 18:40:36 <woglinde> machine beagleboard
May 07 18:40:47 <woglinde> bitbake gtreamer_ti
May 07 18:40:52 <woglinde> gstreamer
May 07 18:43:21 <kergoth_> woglinde: http://github.com/kergoth/OE-Signatures/blob/master/lib/kergoth.py
May 07 18:43:42 * kergoth_ goes to take the dog out
May 07 18:49:45 <Crofton|work> woglinde, do you care if I pull all the DEF_PREF from the boost recipes?
May 07 18:49:57 <woglinde> crofton lol
May 07 18:50:02 <woglinde> just remove it
May 07 18:50:10 <woglinde> we will fix the failures
May 07 18:50:15 <Crofton|work> ok
May 07 18:50:17 <Crofton|work> will do
May 07 18:50:36 <Crofton|work> everyone I know that knows anything about boost is fine with it :)
May 07 18:51:44 <woglinde> kergoth code looks good to me
May 07 18:52:29 <kergoth_> k.  still plenty to be done, but not seeing any obviously incorrect things is good
May 07 18:52:30 <kergoth_> thanks
May 07 18:53:04 * kergoth_ does wonder if he should move the string->components parsing in Value from a parse method called by __init__ into a classmethod from_string factory
May 07 18:53:27 <Crofton|work> woglinde, done
May 07 18:53:31 <CIA-2> 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r507fca1707 10openembedded.git/recipes/boost/ (4 files): boost : Remove DEFAULT_PREFERENCE = "-1" from all versions.
May 07 18:54:27 <soltys> hm
May 07 18:54:37 <soltys> hi hrw 
May 07 18:54:41 <hrw> hi
May 07 18:54:53 <woglinde> hi hrw
May 07 18:54:53 <hrw> soltys: freebsd is not supported as host now
May 07 18:55:14 <soltys> hrw: that sux ;)
May 07 18:55:25 <kergoth_> it would be good to add it, but i'm sure, as with osx, there's a fair bit of work to be done to do it
May 07 18:55:28 <kergoth_> heh
May 07 18:55:29 <soltys> but it works now in someway
May 07 18:55:33 <woglinde> hrw I am told him how to begin
May 07 18:55:41 <woglinde> to support it
May 07 18:55:44 <hrw> cool
May 07 18:55:46 <soltys> only coreutils fails as for now...
May 07 18:56:06 <woglinde> soltys how did youi solved the nano problem now?
May 07 18:57:10 <soltys> woglinde: adding line in siteinfo.bbclass
May 07 18:57:20 <soltys> and bitbake parses recipes
May 07 18:57:30 <soltys> but it can't compile coreutils
May 07 18:58:23 <soltys> btw is there a way to tell bitbake to use gpatch instead of patch ?
May 07 19:00:10 <kergoth_> soltys: not currently.  the default patchtool is quilt for everything built after quilt-native, so if that was patched to use gpatch, that'd get you most of the way there, then it'd just be the recipes using PATCHTOOL = "patch" as an issue.
May 07 19:00:15 <soltys> because on freebsd there is patch in version 2.1 and after building patch from ports binary file is called gpatch
May 07 19:00:17 <kergoth_> soltys: well, by not currently i mean there's no variable for it
May 07 19:00:27 <kergoth_> soltys: you could change openembedded/lib/oe/patch.py, see the PatchTree class
May 07 19:00:59 <soltys> kergoth_: i copied gpatch -> patch and it works ;) but that is dirty
May 07 19:01:18 <kergoth_> aye
May 07 19:02:35 <Tartarus> khem: Testing a workaround to tune-ppc603e.inc / ppce300c3.inc
May 07 19:02:43 <woglinde> soltys ah sorry yes
May 07 19:02:53 <woglinde> that was the seconde file to edit
May 07 19:03:26 <soltys> woglinde: I just made copy of i386-linux and it seams to work for now
May 07 19:03:38 <soltys> only coreutils  fails to compile
May 07 19:04:05 <woglinde> whats the error?
May 07 19:04:10 <soltys> kergoth_: tomorrow I look at openembedded/lib/oe/patch.py and change it there
May 07 19:04:29 <soltys> woglinde: stty.c:283: error: 'TAB2' undeclared here (not in a function)
May 07 19:04:31 <soltys> stty.c:284: error: 'TAB1' undeclared here (not in a function)
May 07 19:04:39 <kergoth_> google? :)
May 07 19:04:49 <kergoth_> i'm sure someone has tried to build coreutils on freebsd at some point
May 07 19:04:49 <woglinde> hm intressting
May 07 19:04:58 <woglinde> kergoth jupp
May 07 19:05:14 <soltys> kergoth_: coreutils from ports builds..
May 07 19:05:17 <svolpe> I have a package that is compiling and saying Note: Legacy staging.  What in the package is making it use legacy staging?  is it because there is a do_staging() {true} function?
May 07 19:05:22 <kergoth_> soltys: and is it patched?
May 07 19:05:25 <woglinde> soltys look at patches
May 07 19:05:29 <woglinde> kergoth *g*
May 07 19:05:31 <kergoth_> :)
May 07 19:05:31 <soltys> will look at them
May 07 19:05:52 <kergoth_> svolpe: new staging populates staging from do_install, rather than a separate task for it
May 07 19:06:01 <kergoth_> svolpe: so yes, defining a non-standard do_stage will do it
May 07 19:06:08 <woglinde> http://www.freshports.org/sysutils/coreutils/
May 07 19:06:12 <soltys> yeap there is patch for that
May 07 19:06:13 <svolpe> kergoth_: ok great, thanks I will remove it.
May 07 19:06:32 <kergoth_> svolpe: not always that simple, but hopefully it is in your case :)
May 07 19:07:30 <woglinde> soltys you can add patches per arch
May 07 19:07:39 <woglinde> in oe recipes
May 07 19:07:49 <soltys> woglinde: ok will do
May 07 19:07:54 <soltys> and send it to ml
May 07 19:07:58 <svolpe> kergoth_: well I have already fixed all the staging bugs with the package, I just need to do a couple of things before the staging so I will just do them in do_compile_append() as that should be fine.
May 07 19:08:06 <woglinde> soltys yes git patches please
May 07 19:08:10 <kergoth_> soltys: you can use the "build-${BUILD_OS}" override
May 07 19:08:16 <kergoth_> svolpe: ah, indeed
May 07 19:08:17 <soltys> woglinde: np ;)
May 07 19:08:21 <soltys> kergoth_: ok thanks
May 07 19:08:39 <soltys> will do it in ~hour or so
May 07 19:08:40 <woglinde> kergoth hm?
May 07 19:08:45 <kergoth_> though, actually, the target os override would be best for that one, since its a -native
May 07 19:08:48 <kergoth_> heh
May 07 19:09:15 <woglinde> I think its rather a code than build problem
May 07 19:33:14 <khem> Tartarus: ok
May 07 19:34:04 <khem> Tartarus: make sure that if you add -O2 in tune-ppc file then it ends after -Os
May 07 19:34:19 <khem> because whatever O is last is the one gcc will take
May 07 19:35:33 <khem> Crofton|work: hey patchwork was not showing latest patches
May 07 19:35:58 <Crofton|work> yeah
May 07 19:36:07 <Crofton|work> I don't know how they get tehre though
May 07 19:36:24 <khem> Crofton|work: ok who maintains our patchwork 
May 07 19:36:30 <Crofton|work> I only know about the user accounts
May 07 19:36:32 <Crofton|work> heh
May 07 19:36:34 <Crofton|work> not sure
May 07 19:36:38 <Crofton|work> I am going to ask on the list
May 07 19:36:59 <Crofton|work> just trying to kill bugs atm
May 07 19:53:14 <woglinde> re
May 07 20:27:13 <kergoth> hmm
May 07 20:27:23 <CIA-2> 03Denys Dmytriyenko <denis@denix.org> 07org.openembedded.dev * r40acd2cdef 10openembedded.git/recipes/ti/matrix-tui_svn.bb: 
May 07 20:27:23 <CIA-2> matrix-tui: bump the rev for latest fixes
May 07 20:27:23 <CIA-2> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
May 07 20:27:32 <CIA-2> 03Denys Dmytriyenko <denis@denix.org> 07org.openembedded.dev * ra316d1e1af 10openembedded.git/recipes/ti/matrix-gui_svn.bb: 
May 07 20:27:33 <CIA-2> matrix-gui: bump the rev for latest fixes, sans external browser binary
May 07 20:27:33 <CIA-2> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
May 07 20:27:34 <CIA-2> 03Denys Dmytriyenko <denis@denix.org> 07org.openembedded.dev * r3902877402 10openembedded.git/recipes/ti/am-benchmarks_svn.bb: 
May 07 20:27:34 <CIA-2> am-benchmarks: bump the rev for latest fixes
May 07 20:27:34 <CIA-2> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
May 07 20:27:59 <woglinde> re pb
May 07 20:28:30 <khem>  xdais_6_25_02_10_eng.tar.gz cant be downloaded from the urls
May 07 20:28:33 <khem> it has
May 07 20:28:37 <pb_> re
May 07 20:28:45 * pb_ taking a short break from packing
May 07 20:28:50 <denix> khem: 1 sec
May 07 20:29:01 <woglinde> khem are you testing the build?
May 07 20:29:03 <woglinde> he denix
May 07 20:29:06 <khem> woglinde: yes 
May 07 20:29:18 <woglinde> denix with binutils 2.18 codecs are building
May 07 20:29:18 <khem> hi pb_
May 07 20:29:27 <denix> khem: that's "eng" drop, not public yet
May 07 20:29:28 <pb_> hi khem
May 07 20:29:38 <khem> pb_: why are you packing
May 07 20:29:39 <denix> woglinde: ah, interesting :)
May 07 20:29:42 <woglinde> khem cgt you have to download too
May 07 20:29:44 <khem> vacation time ?
May 07 20:29:51 <pb_> moving house
May 07 20:30:02 <woglinde> denix with binutils 2.19 and 2.20 there are the linkerscript failure
May 07 20:30:03 <khem> oh moving is always painful 
May 07 20:30:15 <woglinde> I discussed it with khem already
May 07 20:30:27 <soltys> I'm back. How to use that "build-${BUILD_OS}" override ?
May 07 20:30:28 <khem> denix: then why is it in recipes :)
May 07 20:30:54 <woglinde> khem the dl url points to existing domain
May 07 20:30:59 <woglinde> thats the problem
May 07 20:31:08 <denix> khem: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/ti/ti-xdais_6.25.02.10.bb
May 07 20:31:19 <denix> khem: getting ready for the release... :)
May 07 20:31:50 <woglinde> soltys hm grep in recipes
May 07 20:31:56 <woglinde> maybee there is an example
May 07 20:32:17 <denix> although, I would not put a real URL in there, if it's not accessible outside ti.com...
May 07 20:32:29 <soltys> woglinde: ok
May 07 20:32:46 <khem> denix: I have same recipe but still it does not look into this custom link
May 07 20:33:34 <denix> khem: I wonder why it tries to build it... what's your CE_VERSION?
May 07 20:33:49 <khem> denix: http://pastebin.com/RmS8N9bn
May 07 20:34:11 <khem> its looking for the link
May 07 20:34:19 <khem> but fails to dnld
May 07 20:34:19 <woglinde> re mickeyl
May 07 20:34:24 <mickeyl> evening
May 07 20:35:00 <Crofton|work> mickeyl, it appears python cheetah needs to RDEPENDS = "python-neterver"
May 07 20:35:10 <Crofton|work> do you mind if I add that?
May 07 20:35:15 <Crofton|work> netserver :)
May 07 20:35:26 <denix> khem: right, because that url is not accessible from outside TI, afaik
May 07 20:35:34 <mickeyl> Crofton|work: no,sounds good
May 07 20:35:35 <Crofton|work> stupid TI urls :)
May 07 20:35:37 <khem> oh what a PITA
May 07 20:35:44 <Crofton|work> should it also DEPEND on python?
May 07 20:35:46 <denix> khem: but the thing is, it shouldn't even try to dnld it
May 07 20:36:09 <khem> denix: why not
May 07 20:36:09 <woglinde> crofton yea
May 07 20:36:16 <Crofton|work> ok
May 07 20:36:25 <woglinde> crofton but besides cgt and dais all downloads are public
May 07 20:36:27 <Crofton|work> I'll push those when I have a chance to check
May 07 20:36:31 <denix> khem: 6.25.02.10-eng is only used for CE 2.25.02
May 07 20:36:42 <Crofton|work> woglinde, I am just hassling denix :)
May 07 20:36:49 <CIA-2> 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * rc31bade57d 10openembedded.git/recipes/vala/ (4 files): 
May 07 20:36:49 <CIA-2> vala: 0.8.0.95-e7a7 -> 0.8.0.128-1150
May 07 20:36:49 <CIA-2> Also convert to BBCLASSEXTEND = native
May 07 20:36:51 <woglinde> crofton you bad guy
May 07 20:36:59 <CIA-2> 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * r9d6c613be4 10openembedded.git/recipes/iw/iw_0.9.19.bb: iw: add 0.9.19
May 07 20:37:14 <mickeyl> Crofton|work: python-netserver should make it DEPEND on python, no?
May 07 20:37:17 <denix> Crofton|work: yeah, your are bad! :)
May 07 20:37:35 <Crofton|work> netserver would be a RDEPENDS
May 07 20:37:47 <woglinde> so let me see if my sd card is broken
May 07 20:37:55 <woglinde> will test the dsplink stuff
May 07 20:38:01 <kergoth> hmmmm
May 07 20:38:06 <woglinde> re kergoth
May 07 20:38:07 <Crofton|work> the DEPEND on python makes sure netserserer gets built
May 07 20:38:09 <denix> khem: are you trying CE 2.25.02? that's not enabled by default
May 07 20:38:15 * kergoth wonders how difficult itd be to re-implement private staging, but without the other changes he did in his previous prototype
May 07 20:38:24 <khem> denix: I dont know I just tried to bitbake gstreamer-tu
May 07 20:38:28 <Crofton|work> although I suspect that python will be built first unless you try really hard
May 07 20:38:30 <khem> gstreamer-ti
May 07 20:38:47 <denix> khem: which distro? angstrom?
May 07 20:38:50 <khem> kergoth: I would love to have multiple staging
May 07 20:38:59 <denix> if not, I think I know what the problem is...
May 07 20:39:05 <khem> denix: no its minimal but I leech angstrom mirrors too
May 07 20:39:08 <kergoth> i'm sick of things like perl-native and python-native that are only needed for the cross versions breaking shit that uses perl and python
May 07 20:39:23 <woglinde> khem hm I said use angstroem
May 07 20:39:27 <woglinde> *sigh*
May 07 20:40:05 <khem> woglinde: thats ok. atleast we found a problem
May 07 20:40:14 <denix> khem: mirrors won't help. angstrom sets preferred versions right... ce-2.25.01 and xdais-6.25.01.08
May 07 20:40:27 <woglinde> and cgt
May 07 20:40:33 <khem> denix: I will add that to my local.conf
May 07 20:40:39 <denix> khem: I guess I should lower default preference for that recipe and remove the bogus url...
May 07 20:40:54 <pb_> kergoth: not impossible, I think.  I started trying to do that a couple of months back, but I got sidetracked into trying to redesign packaged-staging and never actually finished anything.
May 07 20:41:03 <khem> yes IMO having a downloadable tars for all is nice
May 07 20:41:18 <kergoth> pb_:  heh, did you actually try doing a prototype of your using the existing packages idea?
May 07 20:41:25 <denix> khem: check conf/distro/include/angstrom-codec-engine*
May 07 20:41:37 <denix> too bad those incs are angstrom-specific...
May 07 20:41:51 <khem> denix: even better I will just require it in my local.conf
May 07 20:42:03 <pb_> kergoth: yeah, that was what I was working on.  it turned out to be a larger project than I had originally anticipated because lots of stuff (i.e. cross and native) doesn't/didn't generate any packages at all.
May 07 20:42:28 <pb_> kergoth: so, had to fix that first, which was the original motivation for the toolchain-desuck branch
May 07 20:42:34 <kergoth> ahh
May 07 20:42:51 <kergoth> wouldn't think it'd be horribly difficult to get native/cross emitting packages
May 07 20:42:58 <rhc> hey denix, khem, you guys use OE on davinci boards?
May 07 20:43:11 <pb_> no, it's fairly easy, and in fact a lot of crazy special-case code goes away if you do
May 07 20:43:22 <denix> rhc: sure
May 07 20:43:35 <kergoth> nice
May 07 20:43:36 <khem> rhc: I dont have davinci but I use it on other omaps
May 07 20:43:41 <pb_> I think the current bits in toolchain-desuck do that fairly well.  I just never got around to changing the gcc-runtime to be packaged correctly.
May 07 20:43:52 <kergoth> ah
May 07 20:44:08 <pb_> there is a bit of an issuette around libgcc and stuff if you start generating native packages, because it tends to come out with the wrong PACKAGE_ARCH
May 07 20:44:38 <pb_> (since gcc-cross itself is built for BUILD_SYS, but what you actually want is a libgcc for HOST_SYS)
May 07 20:44:49 <khem> pb_: will dividing up gcc recipes help
May 07 20:44:50 <kergoth> heh, guess cross stuff would ideally have a package_arch that includes both build and target
May 07 20:44:57 <rhc> denix: is it true TI doesn't officially support OE or montavista 6?
May 07 20:45:10 <khem> may be we can have cross ipks 
May 07 20:45:16 <rhc> i asked the platform guy here why we don't use OE, he said they only support up to pro 5.0
May 07 20:45:25 <pb_> well, I think the right answer to that particular problem is to separate out libgcc (and libstdc++, etc) into a separate recipe which can be built for PACKAGE_ARCH=HOST_SYS.
May 07 20:45:49 <pb_> it sounds like RP has been trying something along those lines as well, judging from what he said the other day
May 07 20:45:51 <khem> pb_: I and RP were treading that road for a while
May 07 20:45:53 <kergoth> ah, right
May 07 20:46:08 <soltys> woglinde: or I don't know how to use grep or there is nothing like that in recipes
May 07 20:46:10 <khem> but gcc is a sucker 
May 07 20:46:19 <khem> when it comes to building independent components
May 07 20:46:27 <khem> its one big blob 
May 07 20:46:30 <kergoth> still need to revisit the arch in pstage issues for native and cross, but i guess if you get the use of target packages working, that particular issue could go away
May 07 20:46:38 <pb_> yeah
May 07 20:47:17 <pb_> I do still feel that re-using the normal packages is a better long term solution than having these special crazy "staging packages"
May 07 20:47:26 <soltys> kergoth: is there an example somewhere how to use the "build-${BUILD_OS}" override ?
May 07 20:47:45 <kergoth> how do you plan to handle DEPLOY_DIR files that aren't currently put in any taget packages?
May 07 20:47:52 <kergoth> soltys: the bitbake manual says how to use OVERRIDES in general.
May 07 20:47:59 <kergoth> soltys: going based on the build or target os is just part of that
May 07 20:48:04 <pb_> kergoth: put them in a package, I guess
May 07 20:48:23 <soltys> kergoth: ok will read that manual ;)
May 07 20:48:46 <kergoth> the way the deploy dir files are handled with pstage right now is ugly anyway, so i guess thatd work :)
May 07 20:48:53 <kergoth> though having a u-boot ipk would be weird.
May 07 20:49:12 <pb_> yeah.  weird, maybe, but conceptually I think it would be cleaner.
May 07 20:49:48 <pb_> kind of along the lines we've talked about before, where the recipe just dumps its build artifacts in ${D} and everything that happens after that is, more or less, generic
May 07 20:50:14 <denix> rhc: directly - no, indirectly - yes
May 07 20:50:39 <kergoth> yeah, that would be nice.  recipes really shouldn't be poking outside their WORKDIR themselves
May 07 20:50:47 <pb_> rather than having recipes jamming files into staging, or deploy, or other weird random places
May 07 20:51:34 <pb_> that stuff has, historically, been the cause of a whole bunch of weird problems where things go wrong if you (re)build the recipes in the wrong order
May 07 20:51:41 <khem> xdctools_setuplinux_3_16_01_27.bin is 173M
May 07 20:52:07 <denix> khem: xdc is a beast, ugly-ugly beast... :)
May 07 20:52:52 <kergoth> hmm, i like that idea of yours.. you could just use a regular old ipk feed as your source of cached binaries to avoid unnecessary rebuilds.. but the danger i see is when we add hashing/signatures.  use of cached binaries is really dependent upon those details, since things need to match up, whereas the target packages are fine with PN/PV/PR/PE
May 07 20:53:04 <denix> rhc: Arago is TI's distro/playground to stabilize OE. official TI releases based on Arago are officially supported...
May 07 20:53:05 <kergoth> hmmm
May 07 20:53:05 <rhc> denix: strange :)
May 07 20:53:27 <rhc> ah
May 07 20:59:02 <CIA-2> 03Denys Dmytriyenko <denis@denix.org> 07org.openembedded.dev * ra4046c81e4 10openembedded.git/recipes/ti/ (ti-codec-engine_2.25.02.10.bb ti-xdais_6.25.02.10.bb): 
May 07 20:59:02 <CIA-2> ti: disable "eng" non-public versions for non-Angstrom users
May 07 20:59:02 <CIA-2> Prevent people not using Angstrom and not including angstrom-codec-engine-*
May 07 20:59:02 <CIA-2> files from picking up the latest versions automatically and fail to download
May 07 20:59:02 <CIA-2> sources from TI internal URLs.
May 07 20:59:03 <CIA-2> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
May 07 20:59:22 <denix> Crofton: let me hassle you for a change... :)
May 07 20:59:39 <denix> Crofton: what's up with patchwork?
May 07 21:00:15 * pb_ bedtime now
May 07 21:00:17 <pb_> night all
May 07 21:00:28 <denix> pb_: gn
May 07 21:01:01 <kergoth> night
May 07 21:01:14 <Crofton> grr, I am not sure how email gets to it :(
May 07 21:02:34 <woglinde> nite pb
May 07 21:02:52 <denix> Crofton: by pigeons?
May 07 21:03:25 <Crofton> it seems that way
May 07 21:03:29 <Crofton> gn
May 07 21:08:12 <khem> denix: | /scratch/oe/omap5912osk/work/omap5912osk-oe-linux-gnueabi/ti-dmai-1_1.0+svnr1-j/temp/run.staging_helper.17908: line 896: syntax error near unexpected token `<'
May 07 21:08:16 <khem> NOTE: package ti-dmai-1_1.0+svnr1-j: task do_setscene: Failed
May 07 21:08:48 <khem> ti-dmai_svn.bb is what its picking is that right
May 07 21:09:01 * kergoth profiles the kergoth.py unit tests
May 07 21:15:33 <khem> denix: I see my machine is omap5912osk
May 07 21:15:39 <khem> ok fixed it locally
May 07 21:20:30 <kergoth> hmm
May 07 21:21:52 <khem> woglinde: I guess I will use your build instead of trying my own
May 07 21:22:02 <khem> I have run out of diskspace 
May 07 21:22:08 <khem> doing angstrom for beagel
May 07 21:22:08 <woglinde> lol
May 07 21:22:25 <khem> my laptop only has 60G 
May 07 21:22:27 <woglinde> know problem
May 07 21:22:30 <woglinde> to mee
May 07 21:22:34 <woglinde> strip git
May 07 21:22:41 <khem> yeah so tell me whats wrong now 
May 07 21:22:53 <khem> did you try to add the right linker option
May 07 21:22:59 <khem> thru gcc
May 07 21:23:04 <woglinde> not for binutils 2.18
May 07 21:26:44 <ant__> hello, anyone got ERROR: Build of virtual:native:/oe/openembedded/recipes/gtk+/gtk+_2.20.0.bb do_compile failed ?
May 07 21:27:10 <ant__> ERROR: Build of virtual:native:/oe/openembedded/recipes/gtk+/gtk+_2.20.0.bb do_compile failed
May 07 21:27:18 <ant__> tk+-native-2.20.0-r8.0/gtk+-2.20.0/modules/input/im-xim.la does not export GTK+ IM module API
May 07 21:28:38 <ant__> ..but on second run finished??
May 07 21:30:02 <kergoth> grr
May 07 21:30:08 <kergoth> fixing pysh is proving to be difficult
May 07 21:34:06 <khem> woglinde: hmm, I have to troll thru the errors again
May 07 21:35:15 <woglinde> ohoh thats
May 07 21:35:17 <woglinde> not good
May 07 21:35:24 <woglinde>  Division by zero in kernel.
May 07 21:35:52 <woglinde> latest omap kerneö
May 07 21:35:55 <woglinde> kernel
May 07 21:39:14 <florian> woglinde: oh yes I have seen this on the beagle
May 07 21:40:18 <woglinde> florian unfornatly afterwards I get Unable to handle kernel NULL pointer dereference at virtual
May 07 21:40:48 <woglinde> seems pm stuff
May 07 21:40:58 <woglinde> omap3_pm_idle
May 07 21:41:07 <florian> woglinde: oh... the latest angstrom one available worked for me... apart from the nasty messageds
May 07 21:43:26 <woglinde> guess I should have tried the kernel before flashing it
May 07 21:43:35 <khem> woglinde: div by 0 are usually compiler artifacts sometime you can curtail the calls by coding differently
May 07 21:43:45 <khem> kernel does not use libgcc
May 07 21:44:17 <woglinde> khem seems to triggered by Power Management for TI OMAP3.
May 07 21:44:21 <khem> gcc 4.5.0 compiled kernel 2.6.31+ dies too
May 07 21:44:41 <khem> woglinde: I can bug kevin hilman if he wrote that :)
May 07 21:44:48 * khem goes to gym
May 07 21:45:16 <woglinde> bye khem
May 07 21:45:27 <Crofton|work> gn
May 07 21:45:42 <woglinde> trying now
May 07 21:45:44 <woglinde> git_arago-project.org.git.people.sriram.ti-psp-omap.git_627293ad28604b22612f9a4a318f64cfab241e22.tar.gz
May 07 21:47:28 <ant__> wtf..
May 07 21:47:30 <ant__> Cannot load module /oe/build/tmp/work/i686-linux/gtk+-native-2.20.0-r8.0/gtk+-2.20.0/modules/input/im-xim.la: /oe/build/tmp/work/i686-linux/gtk+-native-2.20.0-r8.0/gtk+-2.20.0/modu
May 07 21:47:30 <ant__> les/input/.libs/im-xim.so: undefined symbol: g_realloc_n
May 07 21:51:36 <kergoth> okay, I'm thinking we should change the exception handling in variable expansions, somehow.  The current method of just emitting the info into the file object where emit_env is going is not ideal
May 07 21:51:50 <kergoth> probably just let them go on up the line, don't catch them
May 07 21:52:08 <kergoth> maybe wrap in an exception to hold the variable name with the right traceback
May 07 21:52:38 <kergoth> shit.. i just realized that it isn't just a little bug in pysh to fix this, it's something they never implemented
May 07 21:52:43 <kergoth> time to learn PLY
May 07 21:53:43 <kergoth> hmm, well ,they did create rules for this, but they don't work, and they're no-ops, they don't construct an object for the ast
May 07 21:54:23 <kergoth> grr
May 07 21:54:32 <kergoth> this is the main thing stopping me from trying to do the bitbake integration
May 07 22:17:18 <ant__> ok, I see in Tinderbox gtk+-native failed in the same way for others...
May 07 22:18:10 <ant__> a.g. for kaeilos both ver 2.18.6-r4 and 2.20.0-r8
May 07 22:37:37 <ant__> it seems this g_realloc_n comes from libglib-2.0
May 07 22:38:23 <ant__> should glib-2 be listed in the dependencies of gtk+-native ?
May 07 22:53:08 <ant__> .. /opt/devel/build/kaeilos/tmp/staging/i686-linux/usr/lib/libglib-2.0.so 
May 07 22:53:13 <ant__> it seems..
May 07 22:55:39 <kergoth> hrm
May 07 23:00:39 <playya> is it possible to set a EXTRA_OECONF option dependent on the use kernel headers version?
May 07 23:01:14 <kergoth> with a python snippet, sure
May 07 23:01:19 <kergoth> not via normal overrides
May 07 23:01:28 <playya> I'm using a 2.6.24 kernel without  fallocate, which is required by util-linux-ng
May 07 23:01:45 <playya> hmm. never used the python voodoo inside a bb
May 07 23:01:53 <kergoth> git grep '${@'
May 07 23:02:01 <kergoth> may need to escape that $, but you get the idea ;)
May 07 23:04:00 <playya> git grep -i '${@.*version' works fine
May 07 23:04:31 <kergoth> nice
May 07 23:04:46 <kergoth> could check for EXTRA_OECONF.*${@ too
May 07 23:04:51 * kergoth wanders off for a bit
May 07 23:05:37 <playya> recipes/kexecboot/linux-kexecboot.inc defines exactly what i need
May 07 23:06:08 <playya> i could do what a good jounalist would do: ctrl +c, ctrl +v
May 07 23:26:55 <ant__> playya: probably you can do it with just base_version_less_or_equal
May 07 23:27:18 <ant__> I wrote that horrible hack temporarly...
May 07 23:42:30 <kergoth> hmmm
May 07 23:44:03 * kergoth thinks about how to possibly integrate 'dirty' state tracking into this code so that a setVar() automatically results in re-expansion of all VariableRefs pointing at it
May 07 23:45:36 <kergoth> I guess I could keep a registry of the VariableRefs and have the value creation factory automatically dirty the appropriate refs and the values including them
May 07 23:47:06 <kergoth> hmm, need a mapping of variable name<->VariableRef(name), and a mapping from the VariableRefs back to the Values containing them
May 07 23:47:47 <kergoth> ugh.. 
May 07 23:48:28 <kergoth> i suspect createCopy of datasmarts will break the variable ref code, since currently VariableRef is bound to a specific datasmart, not the "last" one
May 07 23:48:34 <kergoth> hrm
May 07 23:49:35 <kergoth> think we will need some form of versioning of Value instances based on where they're constructed and the level of the datasmart
May 07 23:50:20 <kergoth> right.. drop the direct inclusion of Values in the components in favor of a version specific VariableRef..
May 07 23:51:51 <kergoth> though, it doesn't really want a specific verison, if we want to be able to, say, inject an extra layer.. it wants whatever version exists at that position, given the current versioning scheme
May 07 23:51:59 * kergoth thinks
May 07 23:53:15 <kergoth> this is where i stalled in my old prototype.  trying to make the dirty state stuff work properly when you have COW datasmart instances
May 08 02:08:56 <kergoth> hmmmm
May 08 02:09:10 * kergoth thinks about how to fit conditional append/prepend into this
**** ENDING LOGGING AT Sat May 08 02:59:56 2010