**** BEGIN LOGGING AT Sat Jul 05 02:59:57 2008
Jul 05 06:59:46 <keesj> I have this funny problem with console-image. every second package it runs fails in the do_patch becuase the source was not unpacked
Jul 05 07:00:07 <keesj> if I run bitbake -c clean thePackage ; bitbake thePackage it works
Jul 05 07:00:14 <keesj> http://www.paste-it.net/raw/public/lb1631a/
Jul 05 07:03:40 <keesj> I also see that the task number goes from 340 to 392 ?
Jul 05 07:20:56 <keesj> I did remove the "work" dir
Jul 05 07:21:06 <keesj> perhaps that was not allowed
Jul 05 08:29:17 <CIA-24> 03koen 07org.oe.dev * r0cfaa3e7... 10/ (1 packages/libtool/libtool-native_2.2.4.bb): libtool-native 2.2.4: fix forced stagings
Jul 05 08:35:40 <keesj> is ik ok to remove the work directory?
Jul 05 08:36:32 <CIA-24> 03koen 07org.oe.dev * r74faa5cb... 10/ (3 files in 3 dirs): boot 1.33.1: add fedora and gentoo patches for gcc 4.3 support and an extra patch hunk stolen from 1.34.1
Jul 05 08:40:35 <CIA-24> 03koen 07org.oe.dev * rd8335534... 10/ (4 files in 3 dirs): gnash: add missing patch
Jul 05 10:05:29 <CIA-24> 03koen 07org.oe.dev * r04757095... 10/ (1 packages/swfdec/swfdec-mozilla_0.7.2.bb): swfdec-mozilla: add NPAPI browser plugin for flash, works with webkit
Jul 05 10:23:30 <CIA-24> 03koen 07org.oe.dev * r3a57bfff... 10/ (1 packages/gnash/gnash-minimal.inc): gnash-minimal: depend on libtool, remove PR from .inc
Jul 05 10:52:30 <CIA-24> 03koen 07org.oe.dev * rd225d46a... 10/ (3 files in 3 dirs): linux 2.6.25: update at32stk1000 defconfig to include pcmcia->usb drivers
Jul 05 11:23:48 <CIA-24> 03koen 07org.oe.dev * rd00fe70e... 10/ (3 files in 3 dirs): gnuradio: add patch to build against gcc 4.3.x
Jul 05 12:33:29 <CIA-24> 03koen 07org.oe.dev * r86723d24... 10/ (3 files in 2 dirs): gnash-minimal: packaging fixes
**** ENDING LOGGING AT Sat Jul 05 12:43:11 2008

**** BEGIN LOGGING AT Sat Jul 05 12:43:32 2008
Jul 05 14:49:59 <Crofton> gm
Jul 05 15:26:38 <Crofton> hrw|gone, ping
Jul 05 16:37:54 <paulproteus> I want to create a new branch in the OE mtn for some work on the OpenMoko distribution, as discussed at http://www.openmoko.org/wiki/Stable_Hybrid_Release
Jul 05 17:10:19 <mwester> paulproteus:  No need for a new branch unless the project destabilizes existing work; new images can simply be added to the existing dev branch.
Jul 05 17:11:11 <paulproteus> So I'm fairly a OE newbie; hopefully you can help me understand things. (-:
Jul 05 17:11:20 <paulproteus> The idea is that we create a new image name, it's true.
Jul 05 17:11:34 <paulproteus> But that image name would build existing bb packages with our own patches.
Jul 05 17:11:55 <paulproteus> Wouldn't that require a separate branch in OE?  Or not - is it something we can customize as part of the image we are building?
Jul 05 17:12:18 <paulproteus> (Where are the docs on this?)
Jul 05 17:12:38 <paulproteus> I presume the way to go is to use mtn for the time being, and just move to git when all of OE moves to git.
Jul 05 17:14:46 <mwester> A bb package is nothing more than a recipe that describes how to create a ".ipkg" (or similar) from a source tarball (or similar).
Jul 05 17:15:15 <mwester> Other bb recipes describe how to create a .jffs rootfs image from a collection of .ipkgs
Jul 05 17:15:26 <CIA-24> 03koen 07org.oe.dev * rb3923131... 10/ (1 packages/oprofile/oprofile_cvs.bb): oprofile: def_pref -1 the cvs version
Jul 05 17:15:55 <mwester> Various other files can be used to constrain choices, such as selecting a preferred version of a tarball, or selecting jffs vs some other image format.
Jul 05 17:16:24 <paulproteus> Maybe what I should do is just try creating a mtn build target for this "SHR" image and try modifying some bb files.
Jul 05 17:16:33 <paulproteus> Then I would actually know what I was talking about.
Jul 05 17:17:10 <mwester> Yep.  I'd start by doing "bitbake fso-image" to build the existing fso image -- or even the minimal fso image as it might make things more clear.
Jul 05 17:17:37 <mwester> The key is that the core build tool (bitbake) is the same between OE and OM; as are most of the .bb recipes.
Jul 05 17:18:23 <mwester> So the MokoMakefile can be easily modified to do much of the housekeeping, simplifying things for the general users.  Core devs, though, should be familiar with how to use bitbake to build a specific recipe.
Jul 05 17:18:35 <paulproteus> Right, and that's what I need to learn. (-;
Jul 05 17:18:54 <paulproteus> More seriously, I need to figure out in what ways our BB files can differ from the mainline 2007.2 applications' bb files.
Jul 05 17:19:14 <mwester> I suggest that before anyone gets too far along with bitbake et al, it wouldn't be a bad idea to start with a known distro (2007.2 or fso), and assemble rootfs's by hand for a bit.
Jul 05 17:19:36 <paulproteus> "assemble rootfs's by hand" - do you just mean using bitbake instead of MokoMakefile?
Jul 05 17:19:57 <paulproteus> Or do you mean asking bitbake local.conf to generate tar.bz2 images instead and me "by hand" running the tar2jffs thing?
Jul 05 17:20:05 <mwester>  By using opkg install, and by copying/editing files as necessary.
Jul 05 17:20:29 <paulproteus> Oh, I see - modify the packages, opkg install onto the device, and then snapshot the device?
Jul 05 17:21:04 <mwester> By analogy, it's like when one builds an application from scratch, one may have a very basic Makefile -- you usually don't mess with making the software fully "automake-compliant" until after it works and is ready for release.
Jul 05 17:21:36 <paulproteus> Right, okay.
Jul 05 17:21:46 <paulproteus> (so that's a yes to the "oh I see"?)
Jul 05 17:21:57 <mwester> not entirely...
Jul 05 17:22:10 <Laibsch> rkirti: I pushed some changes in dasher-gpe
Jul 05 17:22:11 <paulproteus> Further clarifications welcome... (-:
Jul 05 17:22:14 <mwester> the user instructions to begin with would look sorta like:
Jul 05 17:22:19 <Laibsch> rkirti: Go and take a look
Jul 05 17:22:36 <mwester> a) flash the <insert base image name here> image.
Jul 05 17:22:37 <Laibsch> rkirti: Instead of do_fetch it now fails in do_compile
Jul 05 17:22:49 <Laibsch> rkirti: Maybe you have the energy to figure it ouw
Jul 05 17:22:50 <Laibsch> out
Jul 05 17:22:53 <mwester> b) opkg install <list of standard additional packages, such as python, etc>
Jul 05 17:23:19 <mwester> c) edit the following files, use wget to fetch the following files, etc.
Jul 05 17:23:47 <mwester> Once it gets to a "alpha-test" state, we can formalize the last steps into ipkgs, and then the first release is just steps a) and b).
Jul 05 17:24:09 <mwester> For beta (or equiv) on can create a new image that includes the new packages, and it becomes just a)
Jul 05 17:25:11 <paulproteus> "the following files"?
Jul 05 17:25:25 <paulproteus> If the idea is to patch applications, then it's not like I'm going to be editing object files by hand (-:
Jul 05 17:25:44 <paulproteus> But I guess I could recompile the apps with my patches and copy the changed files over to the device's filesystem.
Jul 05 17:25:51 <mwester> Yep. 
Jul 05 17:25:59 <paulproteus> Okay, I'm starting to get it. (-:
Jul 05 17:26:08 <mwester> Once the patches stabilize, we can add them to OE.  until they are stable, that's just a lot of overhead!
Jul 05 17:26:16 <paulproteus> Okay, great!
Jul 05 17:26:51 <mwester> So what is needed is a place to develop the custom packages, and store patches until they have reached some stable point -- perhaps the OM project repo?
Jul 05 18:25:44 <khem> http://www.geek.com/netgear-introduces-open-source-router-20080701/
Jul 05 20:13:03 <CIA-24> 03steve 07org.oe.dev * r11459ed5... 10/ (3 files in 3 dirs): u-boot git: beagleboard: initialize CM_CLKSEL_DSS register
Jul 05 20:54:25 <likewise> hi
Jul 05 23:37:18 <CIA-24> 03koen 07org.oe.dev * r42ef1496... 10/ (3 files in 2 dirs): ipkg-utils*: fix PR values. OE doesn't use split PRs, so stop commiting them!
**** ENDING LOGGING AT Sun Jul 06 02:59:56 2008