From: Ben E. <be...@cy...> - 2006-06-01 18:17:13
|
I made some minor updates to microcom which enable better use in scripts. I tried to contact the developer but he didn't reply. Does anyone know if this software is being maintained at all? If not how would I go about contributing fixes/enhancements to this for gumstix releases. Ben |
From: Dave H. <dhy...@gm...> - 2006-06-01 18:21:19
|
Hi Ben, On 6/1/06, Ben Erridge <be...@cy...> wrote: > I made some minor updates to microcom which enable better use in > scripts. I tried to contact the developer but he didn't reply. Does > anyone know if this software is being maintained at all? If not how > would I go about contributing fixes/enhancements to this for gumstix > releases. I'd create a patch file that gets applied after the original version is untarballed. Send it to Craig, who can integrate it into SVN. You should also figure out what needs to be changed in the makefile and send that along as well. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2006-06-02 00:48:03
|
On Jun 1, 2006, at 11:21 AM, Dave Hylands wrote: > Hi Ben, > > On 6/1/06, Ben Erridge <be...@cy...> wrote: >> I made some minor updates to microcom which enable better use in >> scripts. I tried to contact the developer but he didn't reply. Does >> anyone know if this software is being maintained at all? If not how >> would I go about contributing fixes/enhancements to this for gumstix >> releases. > > I'd create a patch file that gets applied after the original version > is untarballed. Send it to Craig, who can integrate it into SVN. > > You should also figure out what needs to be changed in the makefile > and send that along as well. Yup, generally the best thing to do is to sign up for your own subversion subdirectory here: http://www.gumstix.org/svn-management/ Once you have your directory, then branch the trunk into your directory, as detailed at the end of that svn signup thing. Then add patch(es) in package/somefoo/somefoo-description.patch in your branch, and commit them. Then email me saying something like "take a look at http://svn.gumstix.org/gumstix-buildroot/users/something revision 12345" along with a description of what the revision does, if it's not detailed in the svn log (which you should do). Then I can very easily just merge that revision back onto the trunk with one simple SVN operation. Second best if you don't want to go through creating your own SVN branch is to make the changes off a checked out copy of the main subversion trunk, then just do: cd /path/to/buildroot svn diff -bBdu > ~/somefile.patch Then email me that somefile.patch along with a description of what it does. 3rd best would be to just send me the extra somefoo-description.patch files and say "just drop these into the package/somefoo directory" along with a description of the changes. I'm planning on transitioning all the packages to use quilt instead of the patch-kernel.sh script for applying patches, which should make doing incremental updates a lot easier -- right now linux and u-boot both use what I'm planning on rolling out everywhere, and it seems to work really nicely for me. I've defined an alias: alias qp='export QUILT_PATCHES=`cat .patched`' which allows me to just cd into build_arm_nofpu/linux-x.y.zgum, run the alias, and then "quilt edit" as I want to. At the end, I can svn add any new patches, and everything's all set. Being able to easily push/pop through the patch stack is very helpful too. C |