bitbake fso-image: git://git.freesmartphone.org/usaged.git hung up unexpectedly
rod at whitby.id.au
Fri Aug 22 01:59:34 CEST 2008
Russell Sears wrote:
> Thanks for producing the feeds for FSO, and FsoMakefile! There was a
> great need for such a thing.
Thanks for the kind words.
> However, I think FsoMakefile would be a poor solution for me. I'd like
> to make sure I'm not too far off base, since there's little
> documentation on this stuff (and I plan to fix that problem...). On the
> other hand, the last thing we need is "Yet Another Way To Do Things" if
> there's no real need. ;)
> I'm building the feed myself because I have a few changes that I'd like
> to make to FSO.
> I wrote a few patches that aren't in mainline yet, I want to package a
> library or two, etc... Also, I'm sick of manually copying binaries to
> /usr/bin, typing -force-depends and playing gross tricks like that.
> The long term plan is to put a git server up somewhere that people can
> pull off of, along with auto-built feeds of the 3-5 packages I've
> modified. I'll append some string to the end of the version numbers so
> that "opkg upgrade" automatically pulls in my packages.
> I think this is the way that everyone should do it. It would let users
> compile third party stuff by applying patches to FSO, SHR, 2007.2's
> packages/ directory, instead of doing hacks or editing .bb files...
I think OE overlays are the way to do here. In fact, that's the plan
for the SHR distribution - they are going to structure their svn/git
repository as an OE overlay, and then the Fso Makefile will just check
out that overlay and build images from the combination of the upstream
OE repository and the SHR overlay repository.
> Anyway, back on topic:
> [Moko|Fso]Makefile hides the details of what's going on, while manually
> doing the git pull, and configuring the .conf makes it very obvious how
> the whole thing works, so people can figure out how to modify packages,
> and produce/apply patches.
> I think the wiki should point people to your README for setting up build
> servers, and explain git pull and manual bitbake so people can learn how
> to modify packages. Most of the information in there is correct, so
> only a few changes are needed.
> Should the wiki point developers that want to produce patches to the FSO
> build system in monotone or git? I'm guessing that git is the right one
> to document.
OM is git, OE has decided to move to git but hasn't completed the
transition yet. I'd say remove all mentions of monotone whereever possible.
More information about the devel