**** BEGIN LOGGING AT Tue Feb 20 02:59:57 2007 Feb 20 06:37:48 What are the requirements to be able to commit to SVN? Feb 20 06:38:47 hamish: you have to be able to demonstrate your abilities to produce decent work by submitting patches, porting packages, etc. Feb 20 06:39:21 OK, where do I submit patches to? Feb 20 06:44:01 create tickets on dev.openwrt.org Feb 20 06:46:30 I will initially have a load of activity because I have created platform support for a new board with an ARM processor. Feb 20 06:47:24 At this point my additions are limited to a single directory in targets/linux Feb 20 06:47:41 Should I break this down into multiple patches, or create a single patch? Feb 20 06:48:21 hamish: function specific patches are highly preferred. Feb 20 06:50:08 you can submit all patches in the same ticket, but monolithic patches make life much harder for the devs (and any hackers dealing with your patches) Feb 20 06:54:20 <[mbm]> 'lo Feb 20 06:56:26 Thanks - I will look a the most logical way of breaking it up - as a monolithic patch it is 760k, so probably not what the devs would like to see! Feb 20 12:37:06 kaloz * r6329 /trunk/package/madwifi/ (Makefile patches/200-no_debug.patch): disable debugging stuff in madwifi - saves precious flash space :) Feb 20 14:46:40 kaloz * r6330 /trunk/package/wireless-tools/Makefile: fix wireless-tools install *sigh* - thanks Kesha for noticing it Feb 20 21:20:37 nbd * r6331 /trunk/package/madwifi/patches/200-no_debug.patch: fix debug patch for ahb Feb 20 21:25:00 nbd * r6332 /trunk/package/madwifi/patches/200-no_debug.patch: sorry, last commit had a bug Feb 20 21:55:18 nbd * r6333 /trunk/package/madwifi/patches/200-no_debug.patch: nuke even more debug stuff Feb 20 22:05:05 nbd * r6334 /trunk/target/linux/atheros-2.6/files/ (3 files in 2 dirs): add 16MB flash support for ar2315 (who knows...?) Feb 20 22:59:40 florian * r6335 / (packages/net/aodv-uu/ trunk/package/aodv-uu/): Move aodv-uu to trunk/ Feb 20 23:12:15 quicky question, how can I make the build system just download all the sources without it building anything Feb 20 23:12:18 is that easy? Feb 20 23:12:30 a simple yes/no will suffice Feb 20 23:12:35 make download Feb 20 23:12:40 :) Feb 20 23:12:47 followed by "rtfm" or so Feb 20 23:12:50 sorry, "yes" was the answer :) Feb 20 23:13:18 nbd: you forgot to add "rtfm" Feb 20 23:14:21 it isn't in the fm yet :) Feb 20 23:15:09 loswillios: ehr, yeah, I know that, ehr, of course Feb 20 23:37:19 * nbd suggests a new acronym: piitfm Feb 20 23:37:32 (put it in that f... manual) Feb 20 23:38:28 * [mbm] notes 'diy' Feb 21 01:39:11 interesting... http://lwn.net/SubscriberLink/222773/fbd54ecb4519d13d/ Feb 21 02:20:08 <[mbm]> nbd: heh Feb 21 02:20:14 <[mbm]> that is amusing Feb 21 02:21:21 btw. the uml port is going to be more os specific than other parts Feb 21 02:21:26 so i think i will disable the image builder Feb 21 02:22:08 <[mbm]> ok Feb 21 02:22:42 the cross toolchain arch will be the same as the host arch Feb 21 02:23:07 the previous behavior never worked for me Feb 21 02:23:26 (i386 binaries, native compiled x86_64 uml kernel) Feb 21 02:23:48 <[mbm]> hmm yeah, uml is the sort of thing that should be entirely native Feb 21 02:24:17 i still chose to build a toolchain for it Feb 21 02:24:34 otherwise the c library stuff is just too much of a pain **** ENDING LOGGING AT Wed Feb 21 02:59:57 2007