On Mon, Jan 23, 2012 at 10:23:07AM +0000, Bob Ham wrote: > On 23/01/2012 09:45, Martin Jansa wrote: > > On Fri, Jan 20, 2012 at 09:12:38PM +0000, Bob Ham wrote: > >> This commit provides a 2.6.37 kernel with GTA01 support in order to > >> allow working SHR images to be built for the device. > > 19:24 < JaMa> rah: how is it different then previous patch (except > > shr.patch in SRC_URI for gta01)? > > I don't know; I didn't pay much attention to the kernel patches > contained within the previous patch. (I've been much more concerned > with finding a kernel tree that would work.)
Then read at least header of those patches :) openmoko.patch what's in git.openmoko and isn't in vanila release shr.patch is what's in gitorious shr kernel sources and isn't in git.openmoko repo. So release + openmoko.patch is the same as git.openmoko (except stablepatch if applied). > > 19:25 < JaMa> rah: I would prefer to drop shr.patch instead of forcing > > users to download just another git repo > > Well, I suppose I could create a patch file against the appropriate > kernel release but I'm not sure what the point of that is. Why is > downloading a git repo bad? It seems to me that working directly with > the relevant source repository is much simpler and hence better, than > creating a separate patch step and increasing the complexity of the > build system. download size when you're building for multiple machines with same kernel version as base, you can download release tarball just once and then smaller patches on top of it. With just another git recipe for each machine you're redownloading whole repo again again (it wouldn't be bad if fetch2 could pass --reference to shared git repo, but it doesn't do that). And btw git.openmoko.org is down for a while. Cheers, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
