**** BEGIN LOGGING AT Wed Aug 10 02:59:57 2011
Aug 10 03:00:02 <Tartarus> It breaks autoconf, yes
Aug 10 03:00:13 <Tartarus> Sorry I have to go pick up dinner, but hit up google
Aug 10 03:00:15 <Tartarus> this is a known issue
Aug 10 03:00:17 <tzanger> that's a really weird thing to make it break... but thank you
Aug 10 03:00:20 <Tartarus> and yes, a bit maddening
Aug 10 03:00:23 <tzanger> I would not have suspected that
Aug 10 03:00:41 <Tartarus> fwiw google on autoconf linking GNUmakefile to GNUmakefile
Aug 10 03:00:44 <Tartarus> that'll bring up the threads
Aug 10 03:00:46 <Tartarus> adfk now, really
Aug 10 03:01:00 <khem> tzanger: yeah no symlinks plz
Aug 10 03:01:54 <tzanger> ok, thanks guys, I'll fix that
Aug 10 03:02:37 <khem> I think its somewhere in oe wiki too
Aug 10 03:02:47 <khem> one of those getting started docs perhaps
Aug 10 04:04:20 <galak> khem: around?
Aug 10 09:53:21 <Noor> hi everybody ... i have a question regarding udev
Aug 10 09:53:44 <Noor> i observed a difference in oe-core and meta-oe udev recipes
Aug 10 09:54:17 <Noor> meta-oe recipe has touch ${D}${sysconfdir}/udev/saved.uname and other commands but oe-core does not
Aug 10 09:54:35 <Noor> can anybody explain to me why this difference is there
Aug 10 09:55:29 <Noor> secondly meta-oe recipe  is sopying modprob and touchscreen rule but oe-core recipe does not do that
Aug 10 09:55:40 <Noor> *copying
Aug 10 11:28:11 <lumag> hi
Aug 10 11:34:12 <eballetbo> hi all, what's the difference between meta-texasinstruments layer and arago layer ?
Aug 10 12:20:39 <CIA-15> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r3ad3a53545 10bitbake.git/lib/bb/ui/knotty.py: 
Aug 10 12:20:39 <CIA-15> bitbake/ui/knotty: Ensure previous failures aren't masked by a final successful command
Aug 10 12:20:39 <CIA-15> When running bitbake in -k mode, the last command might succeed but we
Aug 10 12:20:39 <CIA-15> still need to preserve any previous failure codes.
Aug 10 12:20:39 <CIA-15> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Aug 10 12:20:40 <CIA-15> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r4d4e01aa3e 10bitbake.git/lib/bb/ui/knotty.py: 
Aug 10 12:20:41 <CIA-15> bitbake/ui/knotty: Ensure 'No Provider' errors set an exit code
Aug 10 12:20:41 <CIA-15> If a No Provider error is shown we need to set the exit code to
Aug 10 12:20:42 <CIA-15> show an error occured too.
Aug 10 12:20:42 <CIA-15> [YOCTO #1322]
Aug 10 12:20:43 <CIA-15> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Aug 10 12:36:27 <CIA-15> 03Yu Ke <ke.yu@intel.com> 07master * rb3e924297d 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed)
Aug 10 12:36:27 <CIA-15> fetcher2: show warning message when checksum is mismatch
Aug 10 12:36:27 <CIA-15> Currently, if checksum mismatch, fetcher will try mirror,
Aug 10 12:36:27 <CIA-15> and if mirror fetching fail, it will show error "Unable
Aug 10 12:36:27 <CIA-15> to fetch URL xxx from from any source" which actually
Aug 10 12:36:28 <CIA-15> hide the real reason and make user confuse.
Aug 10 12:36:28 <CIA-15> so showing warning message will make it more clear.
Aug 10 12:40:48 <CIA-15> 03Joshua Lock <josh@linux.intel.com> 07master * r705d14d1e1 10bitbake.git/lib/bb/cooker.py: (log message trimmed)
Aug 10 12:40:48 <CIA-15> bb/cooker: only emit ConfigFilePathFound for files which were parsed
Aug 10 12:40:48 <CIA-15> When the requested configuration file is found on disk check the
Aug 10 12:40:48 <CIA-15> against the configuration files in __depends/__base_depends to ensure the
Aug 10 12:40:48 <CIA-15> file was parsed before emitting the ConfigFilePathFound event.
Aug 10 12:40:49 <CIA-15> If the requested file wasn't parsed just return (and don't emit).
Aug 10 12:40:50 <CIA-15> Fixes [YOCTO #1246]
Aug 10 12:58:35 <Crofton> pb_, thanks for the adjourning idea
Aug 10 13:35:11 <dickelbeck> Hi, how can I use oenote from a python task within a recipe to debug a problem
Aug 10 13:36:05 <dickelbeck> src_distribute.bbclass is not working, want to see variables within do_distribute_sources()
Aug 10 13:48:18 <dickelbeck> OK, dumb question, python's print function works OK.
Aug 10 13:55:27 <dickelbeck> What variable specifies the destination of bitbake error logging?
Aug 10 13:55:49 <dickelbeck> ERROR: Function 'SRC_DISTRIBUTECOMMAND' failed (see /dev/null for further information)
Aug 10 13:56:01 <dickelbeck> why /dev/null ?
Aug 10 13:57:22 <dickelbeck> Hello anyone home?
Aug 10 13:59:34 <RA_drc> hi, how do i install a windowing system on my angstrom distro?
Aug 10 13:59:45 <pb_> RA_drc: that would be a question for #angstrom
Aug 10 14:01:12 <RA_drc> irc is full of wonders
Aug 10 14:01:13 <RA_drc> thanks
Aug 10 14:10:07 <jilles> dickelbeck, the default for log output for certain tasks is indeed /dev/null, which is very stupid
Aug 10 14:10:53 <dickelbeck> jiles: thanks
Aug 10 14:12:12 <kergoth> dickelbeck, jilles: no, that bug has been fixed in recent bitbake.
Aug 10 14:12:56 <dickelbeck> kergoth: I am using 1.12.0
Aug 10 14:13:14 <kergoth> 1.12.0 isn't recent
Aug 10 14:13:29 <kergoth> well, depends on your definition, but that's certainly before that issue was fixed
Aug 10 14:13:44 <esbenh> kergoth: did you see that I pushed some stuff to the fetching repo?  I have started using it in OE-lite now :-)
Aug 10 14:14:01 <kergoth> didn't see, been pretty busy with work recently
Aug 10 14:14:07 <kergoth> will add to the todo to take alook
Aug 10 14:14:11 <dickelbeck> struggling with src_distribute_local.bbclass' SRC_DISTRIBUTECOMMAND-move+symlink ()
Aug 10 14:14:23 <esbenh> I've been pretty busy sticking to not doing stuff during my 3 weeks vacation :-D
Aug 10 14:14:58 <esbenh> It is only slightly modified from the version I got from you
Aug 10 14:15:11 <dickelbeck> kergoth: OK to use bitbake git master's HEAD?
Aug 10 14:15:26 <kergoth> dickelbeck: or one of the 1.13 releases
Aug 10 14:15:46 <kergoth> ie http://git.openembedded.org/cgit.cgi/bitbake/snapshot/bitbake-1.13.3.tar.gz
Aug 10 14:16:34 <dickelbeck> kergoth: I have a git tree now, but I'm not a frequent git user.
Aug 10 14:16:57 <kergoth> and this is relevant how? if you don't want to use git, don't. download the tarball of the release i just linked
Aug 10 14:18:15 <dickelbeck> kergoth: doing that as a test, but the real issue is that task distribute_sources() is not working, at all, properly.
Aug 10 14:18:35 <kergoth> yes, so use a current bitbake so you can actually see the real error and diagnose
Aug 10 14:18:42 <kergoth> I misplaced my crystal ball, sorry
Aug 10 14:19:32 * kergoth gets food
Aug 10 14:42:28 <dickelbeck> upgraded to bitbake 1.13.3 from 1.12.0, and now it will not parse previously valid recipes?
Aug 10 14:42:53 <dickelbeck> ERROR: Unable to parse /oe/openembedded/recipes/xorg-font/font-util_1.2.0.bb
Aug 10 14:43:35 <JaMa|Wrk> comments in variables?
Aug 10 14:44:25 <dickelbeck> JaMajWrk: was this discussed, as a known issue arising with the introduction of 1.13?
Aug 10 14:44:53 <JaMa|Wrk> yes
Aug 10 14:45:56 <dickelbeck> Thank you.  What was done about it?  How many recipes from openembedded.org dev tree?
Aug 10 14:46:13 <JaMa|Wrk> dickelbeck: http://patches.openembedded.org/patch/789/
Aug 10 14:46:34 <dickelbeck> You are awesome, thanks.
Aug 10 14:46:34 <JaMa|Wrk> I'm not using old tree anymore
Aug 10 14:46:50 <dickelbeck> What is better?
Aug 10 14:47:34 <JaMa|Wrk> oe-core+meta-oe
Aug 10 14:48:11 <dickelbeck> how painful was the switch over, days or weeks?
Aug 10 14:48:35 <JaMa|Wrk> depends on your target
Aug 10 14:49:00 <JaMa|Wrk> and knowledge.. switching whole SHR is still wip for few weeks
Aug 10 14:50:01 <dickelbeck> When you say oe-core and meta-oe, are these combined somehow via overlay?
Aug 10 14:50:10 <JaMa|Wrk> bblayers
Aug 10 14:50:21 <dickelbeck> right
Aug 10 14:51:13 <dickelbeck> I have a distro named Gatecraft, and it is in its own BBLAYER now.  Sounds like a lot of work to re-park it.
Aug 10 16:17:13 <khem> dickelbeck: It should be easy to rebase your distro on oe-core
Aug 10 16:19:18 <tzanger> khem / Tartarus: thank you for pointing out the error of having oedir being the product of symlinks, that was exactyl the issue
Aug 10 16:19:32 <khem> tzanger: cool. np
Aug 10 16:19:39 <tzanger> I found some other troubles with BB_NUMBER_THREADS more than 4, but I think that's a corner case that really doesn't matter
Aug 10 16:20:04 <khem> hmmm what problem ?
Aug 10 16:21:15 <dickelbeck> khem: what is the philosophical difference in oe-core from old dev?
Aug 10 16:21:59 <khem> layering 
Aug 10 16:22:34 <khem> oe-core is highly maintained good quality recipes that can be used with other layers if needed to spin out distro
Aug 10 16:23:16 <kergoth> (theoretically)
Aug 10 16:23:23 <tzanger> khem: it seems that if you do that some dependencies aren't properly tracked and you get things like vlc breaking because it can't find a compiler
Aug 10 16:23:47 <khem> hmmm 
Aug 10 16:23:52 <khem> is that with oe.core
Aug 10 16:24:01 <khem> kergoth: aye
Aug 10 16:24:32 <khem> kergoth: those are charter items which we work towards
Aug 10 16:37:33 <kergoth> khem: out of curiosity, is it easy to build an llvm crosscompiler to arm?
Aug 10 16:37:41 <kergoth> haven't looked at that much yet
Aug 10 16:38:11 <fray> from what I was told at ELC, arm is the best supported on llvm right now
Aug 10 16:38:31 <kergoth> cool
Aug 10 16:58:33 <dickelbeck> anyone here familiar with src_distribute.bbclass, seems I am getting bogus ${SRC} computation in there.
Aug 10 17:02:05 <dickelbeck>         bb.data.setVar('SRC', os.path.abspath(local), d)
Aug 10 17:02:11 <dickelbeck> is the offending line of code.
Aug 10 17:03:36 <dickelbeck> It resolves to /oe/build-x86/work/x86-softplc-linux/busybox-1.15.3-r34.5/busybox-1.15.3/busybox-1.15.3.tar.bz2
Aug 10 17:03:57 <dickelbeck> and the tar is not in that directory, it is in /oe/downloads
Aug 10 17:53:10 <Noor_> HI .... I am looking for the reason of difference in meta-oe udev and oe-core udev ..... can somebody help me?
Aug 10 20:20:57 <fray> working on head of oe-core, I'm getting a translation failure... libstdc++6 is requiring "eglibc", not libc.. or whatever..
Aug 10 20:21:14 <fray> nyone have a clue as to what might be going wrong?  (I'm not using multilibs.. and I'm building for qemuarm)
Aug 10 20:21:32 <fray> I have cleaned both glibc and libgcc as well.. and get the same end result
Aug 10 20:46:06 <khem> fray: are you inheriting debian renaming or not
Aug 10 20:46:39 <fray> it is inheriting it.. I just disabled it and now building the whole set again
Aug 10 20:47:35 <fray> personally I really dislike the debian style renaming.. but I'm trying to live with it.. but it seems to get fragile at times
Aug 10 20:49:16 <jilles> fray, I have noticed problems with debian style renaming too
Aug 10 20:49:54 <fray> today's oe-core?  (this seemed to be working fine yesterday)  I havn't attempted to bisect yet to figure out what might be to blame
Aug 10 20:49:55 <jilles> in particular, if a machine-specific package depends on something arch-specific affected by renaming, it may not work
Aug 10 20:50:06 <jilles> no, somewhat old oe.dev
Aug 10 20:50:53 <jilles> really, the renaming is only useful if you distribute in the form of packages
Aug 10 20:52:24 <fray> many of the devices my customers make are larger devices that need package management
Aug 10 20:54:16 <fray> yup disabling debian renaming fixed my problems.. ugh
Aug 10 20:55:49 <fray> Hmm nothing obvious in the recent patch changes either
Aug 10 20:58:12 <jilles> hmm, I guess this is something else since both libstdc++ and eglibc are not machine-specific
Aug 10 20:59:34 <jilles> the renaming data is stored in a pretty well hidden place
Aug 10 21:00:02 <jilles> I forgot what it was exactly, but I initially didn't find it because it's in a subdirectory of a directory with one file per package
Aug 10 21:00:37 <fray> I cleaned by build directory...
Aug 10 21:00:53 <fray> the only thing I reused was the sstate-cache (minus the deploy-rpm files) and the downloads
Aug 10 21:03:55 <fray> the sstate-cache does cache the package renaming afterall.. so I'll have to try again in a bit with that info wiped... see if it fixes itself..
**** ENDING LOGGING AT Thu Aug 11 02:59:56 2011