If you guys don't mind it taking a little bit of time I can begin
working on the wbe interface. I am proficient in PHP. I can't do
C/C++ yet so I will contribute in this way. Let me know if it's ok to
On Tue, 1 Mar 2005 09:58:39 -0800, Craig Hughes <craig@...> wrote:
> On Mar 1, 2005, at 9:09 AM, David Farrell wrote:
> > What is the official Gumstix line of granting
> > space on the subversion server for other
> > projects?
> "the official Gumstix line" sounds awefully official :)
> My inclination is to basically give access to anyone who wants it to
> people working on "branches" of the gumstix buildroot, for some
> definition of "branches" which basically equates to what I believe
> constitutes a bona-fide branch (me being the arbiter). Such access
> includes a giant disclaimer which states something to the effect of
> "server may go down at any time and we're not liable for loss of access
> -- don't depend on the server being available if it will affect your
> livelihood; your data might get lost in a freak accident, or because I
> type rm -rf / by accident, and we're not liable for that either -- keep
> your own backups if you want them; if you become impotent as a result
> of use of the server, we are not liable -- nor for any other discomfort
> or emotional pain you may experience as a result of use or non use of
> the system".
> I've actually migrated the whole thing over to a much more reliable
> server than it was on previously, and removed the flakey router from
> the path between server and internet, so it's a lot more reliable than
> it was, and in the future it might even get yet better -- but no
> promises there for now.
> > Initially I would like to import a "sample"
> > project which shows examples of building a
> > module, devices driver, etc appropriate for the
> > gumstix platform.
> That'd be great. Essentially, anything which starts off as a svn cp
> from gumstix-buildroot would be great to have in there. Anyone who
> develops something in their own branch, who thinks it'd usefully be
> made available on the trunk for wider consumption can then just send me
> an email saying "You should look at merging rXYZ:ABC onto the trunk
> from branches/myusername/mybranch" then I can quickly and easily do
> that svn merge and decide whether or not to commit, and/or add my own
> changes on top of it. The example projects you mention above would be
> great, especially if you got really excited and wrote the whole thing
> up on the wiki or something as a tutorial :)
> > I think a rule should be that all projects should
> > be installed relative to gumstix_buildroot on
> > users development systems so that makefiles are
> > consistent across buildroot revisions.
> Yes -- basically you should work within the buildroot structure, for 2
> 1. You can easily just do a svn merge from the trunk onto your branch
> to keep your own stuff up to date with the latest and greatest on the
> 2. I can easily merge stuff back from your branch to the trunk if it
> makes sense to do so.
> This means that you should have .mk file in /make, patches to whatever
> "core" software distribution in /sources, and follow the basic setup of
> how the buildroot does things. For people writing original project
> code for gumstix-specific use (ie where there isn't some external
> tarball to download into sources/dl), eg robostix code, I think the
> right thing to do is to create subdirectories under /sources which the
> makefile will copy into build_arm before building (ie the building
> happens in the easy-to-blow-away build_arm directory, keeping /sources
> unmodified by "make" commands except for the dl subdir). So one might
> have, for example:
> [and make/somefoo.mk downloads http://www.somefoo.org/somefoo.tgz]
> > Applications may fall under this as well (If I
> > ever get postgres running) Maybe a script for
> > downloading the application and to patch and
> > build it, much like buildroot.
> Yup, for existing imported applications, you write a .mk and .patch(es)
> and point the .mk at a download site.
> > I expect the robostix development may suitable
> > for this?
> Absolutely. Send me your preferred username and I'll create an
> account, create branches/accountname and send you the password for it.
> I was a while back intending to actually automate this process with a
> web UI which would let people get a username/password/directory very
> easily and automatically update the svn auth database -- but then got
> sidetracked with actual work instead. I'll still probably do it at
> some point though if I'm bored and feel like dropping back into php for
> a little diversion.
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> gumstix-users mailing list
Daniel A. Morrigan
He who says it cannot be done is interrupting the one doing it.