**** BEGIN LOGGING AT Wed Apr 30 03:00:02 2008 Apr 30 03:01:31 frogonwheels: ${IPKG_INSTROOT} Apr 30 03:02:16 thanks Apr 30 03:02:45 ah - and what about the -d option ? Apr 30 03:02:48 I assume it works because the var is undefined on the router. Apr 30 03:03:01 frogonwheels: dunno about the options. Apr 30 03:03:03 oh. ok Apr 30 03:03:30 Bartman007: also - I'm looking at the zaptel Makefile from a pending patch.. Apr 30 03:03:59 Bartman007: - and it's making all the /dev/zap devices... which my devfs doesn't particularly like Apr 30 03:05:04 Bartman007: I assume that udev is similar Apr 30 03:05:35 I can't claim to know anything about Zaptel besides them being VOIP hardware Apr 30 03:05:35 Bartman007: Is it possible to not use either of these? Apr 30 03:07:30 More about the /dev directory management than zaptel Apr 30 03:07:43 yeah, looking into it right now Apr 30 03:07:43 should we be manually creating /dev nodes? Apr 30 03:07:49 cool Apr 30 03:08:00 haven't paid much attention to device node creation yet Apr 30 03:08:17 In devfs they are created no problem. Apr 30 03:08:33 in udev - I guess there could be some rules to write if anything... Apr 30 03:09:03 but not much point in creating the nodes in postinst if it's ona tempfs (which udev generally is) Apr 30 03:11:00 Bartman007: would you know of a good place in the US to get a USB to TTL converter? Apr 30 03:11:37 thepeople: I'm running into the same issue. All my cables fried themselves in the past few months Apr 30 03:12:35 that is unfortunate Apr 30 03:13:09 I used to grab cheap cell data cables, but local sources have dried up as cell phones switch to usb Apr 30 03:13:59 and the cheap ebay cables don't seem to be as robust, or the seller uses a generic picture and ships a different cable. Apr 30 03:14:35 yea, I just had the same problem with a amazon cable I had picked up Apr 30 03:15:21 btw Bartman007 - I've actually got things running - but just wanted to make sure the packages get fixed. Apr 30 03:15:44 I just ordered four standard USB-serial cables, plan on hacking them into usefulness as I can guarantee they are pl2303 based. Apr 30 03:17:35 frogonwheels: I've got my hands full currently, btw, we don't use udev, but hotplug2. Apr 30 03:17:53 oh ok. Don't know anything about hotplug2. Apr 30 03:18:13 where did you get them from? Apr 30 03:18:14 I'll email the list with what I've got. thanks. Apr 30 03:19:32 thepeople: chinese ebay vendor ;-) Apr 30 03:20:24 I know they contain a pl2303, but not sure if they output directly from that chip or use a 3.3V to 5V level converter Apr 30 03:20:57 ok Apr 30 03:22:06 and if they contain a level converter I'll have to see how easy it is to tap into the right pins. Apr 30 03:23:36 good luck, sounds like you will be having fun with that :-P Apr 30 05:16:20 rwhitby * r10986 /trunk/package/kernel/modules/block.mk: block.mk: Added ata-ixp4xx-cf module support for tw5334 board. Apr 30 10:57:10 kaloz * r10987 /trunk/target/linux/generic-2.6/patches-2.6.25/950-revert_conntrack_optimization.patch: revert conntrack optimization, as it's broken on arm Apr 30 10:59:05 kaloz * r10988 /trunk/target/linux/ (16 files in 4 dirs): sync ixp4xx related patches with 2.6.24 and upgrade to 2.6.25 Apr 30 13:31:05 juhosg * r10989 /trunk/target/linux/generic-2.6/config-2.6.25: [kernel] add missing symbols to .25 config Apr 30 13:56:32 juhosg * r10990 /trunk/target/linux/atheros/config-2.6.24: [atheros] resync .24 config Apr 30 15:10:10 juhosg * r10991 /trunk/target/linux/generic-2.6/patches-2.6.25/ (4 files): [kernel] fix some netfilter extensions on 2.6.25 Apr 30 15:42:13 juhosg * r10992 /trunk/ (3 files in 3 dirs): [package] kmod-ipt-iprange: fix build error on .25 Apr 30 19:07:08 nice article about the future of svn: http://blog.red-bean.com/sussman/?p=90 Apr 30 19:25:07 loswillios: i think linus' git talk video deals with svn nicely ;) Apr 30 19:25:31 loswillios: and i totally agree with what he said about branching and merging Apr 30 19:26:24 the svn guys tried hard to make the branching operation efficient, while completely ignoring the merging aspect of it Apr 30 19:26:43 i mean what good is fast branching if merging is painful Apr 30 19:26:54 => svn was looking at the wrong problem entirely Apr 30 19:30:04 :-) Apr 30 19:32:44 i really noticed git's strength when i wanted to hack one some kernel stuff on my laptop, cloned linus' git and then merged in two other branches that were based on different versions Apr 30 19:33:24 took me like five minutes to fix merge conflicts (which were all real conflicts, not false positives created by the version control) Apr 30 19:33:30 and then the new tree was up and running Apr 30 19:33:52 even with much smaller repositories, there's simply no way to do this with svn Apr 30 19:34:12 have you used the svn-git bits? Apr 30 19:34:27 we have svn at work.. I am looking at using git as the frontend.. Apr 30 19:34:30 nbd and myself use them for openwrt. Apr 30 19:34:34 ok Apr 30 19:34:39 i'm using it on every single openwrt checkout that i have ;) Apr 30 19:34:50 I like mercurial.. but hgsvn doesnt support commits to svn.. Apr 30 19:34:57 just checkouts and diffs Apr 30 19:35:08 and I coulndt be bothered to write it :-D Apr 30 19:35:16 git-svn has some issues occasionally, but most of them are minor and easy to deal with Apr 30 19:35:50 it is so nice to be able to create a series of local commits, then be able to test, reorder, squash, rebase them and commit the entire series to svn once you are happy with the results. Apr 30 19:36:11 yeah Apr 30 19:36:56 and btw. when i did the merge that i described above, i was completely new to git. first time i ever tried to do something with it Apr 30 19:39:24 Acinonyx: tell them! Apr 30 19:48:36 hmm, he's not here.. Apr 30 19:48:58 anyway: the point is that he has been following openwrt with a git import all along.. Apr 30 19:53:12 Of course, we'd be happy to share our experiences. Apr 30 19:54:38 sure, please so Apr 30 19:56:29 For one, the steep learning curve is a fact. But, trust my word, it's worth it. Apr 30 19:57:08 i agree Apr 30 19:57:34 Second, svn tools are not perfect, they might skip a few changes/files. We've followed their bugs and many times did a manual check to see that the whole svn tree had been imported. Apr 30 19:59:35 But I'd found ways to correct the inconsistencies. It would, of course, be ideal if the master openwrt repo was in git all along. Apr 30 20:00:55 One other old claim was that, since you will learn git and get to use it, you could have it as a patch-management tool for the packages themselves, like the kernel. Apr 30 20:02:06 That would reform the whole openwrt: the 'openwrt' repo would only contain mostly build instructions, and then call individual git repos with copies-patches of each project. Apr 30 20:02:17 i thought about doing that, but dropped the idea again, because i don't think hiding our patches in a git clone of a package repo is a good idea Apr 30 20:02:32 nbd: agree Apr 30 20:02:51 it's much easier to figure out what changed and why if you have things based on the idea of maintaining patches, not of maintaining the code trees themselves Apr 30 20:03:05 There is always a way to 'expose' those patches again, using a few trivial scripts. Apr 30 20:03:16 IMO if we were going to do something like that it would be worth looking towards stgit, but I don't think it's worthwhile either Apr 30 20:03:16 but the workflow is not designed to support that properly Apr 30 20:03:35 since everything in git is based around the idea of small incremental changes Apr 30 20:03:45 and that's not how package maintaining in openwrt works Apr 30 20:03:52 we try to reduce the number of patches, but keep them well separated Apr 30 20:04:21 What is the management effort like, now? Apr 30 20:04:31 on what specifically? Apr 30 20:04:35 I mean for the hard ones, like the kernel.. Apr 30 20:04:55 well, i have no problems with it using quilt Apr 30 20:05:03 brb Apr 30 22:26:44 Hmm. http://openwrt.pastebin.ca/1003375 ip route fails to build under 2.6.25, but I can't see why that error is being raised Apr 30 22:27:32 It's almost as if __u32 isn't being defined Apr 30 23:57:50 bye bye **** ENDING LOGGING AT Thu May 01 02:59:56 2008