**** BEGIN LOGGING AT Sat Apr 10 02:59:57 2010 Apr 10 04:13:58 dingo * r20772 /packages/net/nocatsplash/patches/001-openwrt_firewall.patch: [patchteam] modified patch added missing ipt_REDIRECT from initialize.fw Apr 10 06:12:06 is there a recommended way to get station stats on the new 10.03-brcm47xx image? Apr 10 06:12:24 iwconfig reporting is kind of sparse too Apr 10 06:12:48 doesn't even show the ssid it is providing Apr 10 06:19:04 oh, found it Apr 10 06:19:18 iw dev wlan0 station dump Apr 10 08:45:46 <_trine> cshore_: ping Apr 10 11:34:15 juhosg * r20773 /trunk/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c: (log message trimmed) Apr 10 11:34:15 Generic: Clean up output of AR8216 driver. Apr 10 11:34:15 This patch is rather a cosmetic patch. It fixes the following issues: Apr 10 11:34:15 * Demote the unknown device message to debug level to not spam Apr 10 11:34:15 the log. Apr 10 11:34:16 * Fix the version print of the unknown device message. Apr 10 11:34:17 * Output the 'attach' message only when attaching as switch driver, Apr 10 11:44:53 I have patches for a gcc 4.5 toolchain Apr 10 11:45:03 would those be worth committing to trunk? Apr 10 11:47:36 juhosg * r20774 /branches/backfire/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c: (log message trimmed) Apr 10 11:47:36 backfire: Generic: Clean up output of AR8216 driver. (backport of r20773) Apr 10 11:47:36 This patch is rather a cosmetic patch. It fixes the following issues: Apr 10 11:47:36 * Demote the unknown device message to debug level to not spam Apr 10 11:47:36 the log. Apr 10 11:47:36 * Fix the version print of the unknown device message. Apr 10 11:47:37 * Output the 'attach' message only when attaching as switch driver, Apr 10 13:43:53 nbd: ping Apr 10 13:44:43 KanjiMonster: pong Apr 10 13:45:39 nbd: regarding the ar8216 driver - was there a reason why you flush the arl table in read status and did not enable the automatic aging (I assume its disabled on the ar8216)? Apr 10 13:47:38 (in the global atu control register) Apr 10 13:49:29 the automatic aging took way too long and without the ATU flushes, transitions from cable to wifi became really slow Apr 10 13:49:35 or vice versa Apr 10 13:50:12 and i did not find a way to tell the ATU to allow nodes moving between ports Apr 10 13:51:46 I see, thanks Apr 10 13:58:39 nbd: can I close this: https://dev.openwrt.org/ticket/6229 with wontfix? Apr 10 14:21:22 rtz2: dunno, it seems that it does describe a real problem, though i do not agree with the proposed fix Apr 10 14:29:03 jow * r20775 /trunk/target/linux/brcm-2.4/base-files/etc/init.d/wmacfixup: [brcm47xx] add script to fixup the wireless mac (#7102) Apr 10 14:31:30 jow * r20776 /branches/backfire/target/linux/brcm-2.4/base-files/etc/init.d/wmacfixup: [backfire] merge r20775 Apr 10 14:31:51 nbd: I will write a comment but keep it open Apr 10 14:43:28 Is there a document explaining the diffirence between teh trunk and backfire branches? Apr 10 14:43:40 not really Apr 10 14:45:06 Does backfire now only receive bug fixes? Apr 10 14:45:07 xl0: trunk is development Apr 10 14:45:29 xl0: yes trunk recievces mostly bug fixes Apr 10 14:45:35 err backfire Apr 10 14:46:53 And how does the development model work? Someone (nbd?) decides that a new major release needs to be done, he forks the trunk and then a few rounds of testing and fixing are performed? Apr 10 14:48:55 no, we have two release managers that do that Apr 10 14:49:22 But otherwise, that's how it works? Apr 10 14:49:55 currently, but we are moving towards a more structured release cycle Apr 10 14:50:06 And after backfire was released, how long until a new stable branch is created? Apr 10 14:50:29 should be ~6 months Apr 10 14:51:09 nbd: another thing Apr 10 14:51:23 nbd: regarding using system ppl and cloog: http://openwrt.pastebin.com/2bFn5w5e Apr 10 14:51:25 Makes sense. Thank you for the explanation. Apr 10 14:51:49 just dont follow the ubuntu example too much. frequent releases, release first, test later. makes users unhappy ;-) Apr 10 14:51:50 nbd: should I send it to the mailinglist or do you want to commit it directly? (or is it unacceptable) Apr 10 14:51:53 there will also be a couple of 10.03.X releases as needed during those 6 months Apr 10 14:52:25 stintel: we want frequent, tested releases Apr 10 14:53:01 thepeople: But only bug fixes are backported, no new features? Apr 10 14:53:17 just my opinion, I would rather have a new stable release once a year, with couple point releases. Apr 10 14:53:26 my 2 best examples: debian is too slow, ubuntu is too fast Apr 10 14:53:45 thepeople: Btw, what does 03 in 10.03 mean? Apr 10 14:53:49 something in between would be nice, but just my two cents ;-) Apr 10 14:54:51 xl0: mostly, we don't have a no new features policy, but the kernel version would remain in the same release series, no invasive new features Apr 10 14:55:00 and a pity, I no longer have a 2nd rspro, it's back to the owner Apr 10 14:55:03 nbd: looking at the patch, line 56/57 seem to enable the graphite option for _CS, but considering that gcc configure pretty much manages this by itself anyway, I doubt this is a problem Apr 10 14:55:47 stintel: the idea of a LTS has been thrown around Apr 10 14:56:33 thepeople: might not be a bad idea, esp. for routers, which I can imagine people dont want to update all that much Apr 10 14:56:49 stintel: so we would have one release with fixes for a year and one 6 month release Apr 10 14:57:25 thepeople: I was perfectly happy with 8.09 for most uses. I only needed trunk for the fancy rspro ;-) Apr 10 14:57:29 i'm not sure, how valuable that is, the amount of fixes you can install before running out of flash is pretty limited Apr 10 14:58:02 rtz2: sysupgrade is fine. as long as the config syntax stays Apr 10 14:58:30 rtz2: this ^ Apr 10 14:59:01 also fixing up sysupgrade to keep *all* configs as marked by opkg is on my list before the next release Apr 10 15:00:34 hmmm time to enforce my clean desk policy once again :> Apr 10 15:00:51 :-P Apr 10 15:01:16 smoking doesn't help :( Apr 10 15:01:30 ok ... Apr 10 15:01:45 gcc 4.5 produces smaller executeables then 4.1 Apr 10 15:01:50 only the kernel gets bigger Apr 10 15:04:16 and libgcc and uclibc Apr 10 15:14:06 rtz2: about that patch: could you add something to add --without-ppl and --without-cloog for the non-graphite case? Apr 10 15:15:11 nbd: you mean pass the the graphite configure setting to gcc? can do Apr 10 15:15:39 afterwards send it to the list please Apr 10 15:46:04 [florian]: ping Apr 10 16:31:44 xMff: hey, thanks for including that ddns patch Apr 10 16:32:00 joda_bot: np Apr 10 16:32:01 xMff: compared to my initial version what did you improve? Apr 10 16:32:20 I noticed you used a filehandle and read it read only etc. Apr 10 16:33:02 is it just more robust that way? glad, I can use it now :D th Apr 10 16:33:24 yes, I always try to avoid accumulating data, therfore I read the file line by line Apr 10 16:43:36 oh good, is there any "user friendly" development environment for luci? (like using Eclispe with RemoteServerExtentions and a Lua Plugin-IDE?) Apr 10 16:50:17 nbd * r20777 /trunk/package/mac80211/ (27 files in 2 dirs): mac80211: update to wireless-testing 2010-04-09, add work-in-progress ar9300 patches Apr 10 16:50:21 nbd * r20778 /trunk/target/linux/ar71xx/profiles/atheros.mk: ar71xx: add a profile for PB92 Apr 10 16:54:46 joda_bot: good question, I have not found a good one yet, maybe luaclipse Apr 10 16:57:11 joda_bot: right now I usually work with sshfs + gedit directly on the device Apr 10 17:20:24 Is there a fundamental reason the generated .cpio.gz can't be used by the kernel build? Apr 10 17:38:48 Could not we move the kenrel compilation to after the images are generated, and point it to the cpio.gz? Apr 10 17:39:28 Or could the kernel itself be included into the image on some architectures, like x86? Apr 10 18:15:24 Sorry if I'm being too noizy, but what does DUMP do? Apr 10 18:33:03 florian * r20779 /packages/net/netatalk/ (Makefile files/afpd.init): [package] remove kmod-appletalk dependency, change description, and make init script executable (#6619) Apr 10 18:33:10 florian * r20780 /packages/net/bird/ (11 files in 3 dirs): (log message trimmed) Apr 10 18:33:11 [package] add package for BIRD Internet Routing Daemon Apr 10 18:33:11 Here is the patch that adds a package for The BIRD Internet Routing Apr 10 18:33:11 Daemon. It is updated to the current version of BIRD (v 1.2.2). Apr 10 18:33:11 BIRD is an internet routing daemon that implements OSPF, RIP and BGP. Apr 10 18:33:11 It is fast, lightweight and small (cca 300 kB), therefore ideal for Apr 10 18:33:11 OpenWRT based routers. Apr 10 18:33:12 florian * r20781 /packages/net/nmap/Makefile: Apr 10 18:33:13 [package] nmap: Add nmap-os-db to package. Apr 10 18:33:14 This patch adds nmap-os-db to the nmap package. Nmap cannot Apr 10 18:33:14 identify OS's without it (actually it doesn't even try). Apr 10 18:33:14 Signed-off-by: Jonas Gorski Apr 10 18:33:15 florian * r20782 /packages/lang/jamvm/Makefile: Apr 10 18:33:16 [package] upgrade JamVM to 1.5.4 Apr 10 18:35:11 florian * r20784 /trunk/package/block-extroot/Makefile: Apr 10 18:35:11 [package] block-extroot depends on kmod-ata-core Apr 10 18:35:11 The package block-extroot depends on some builtin package like Apr 10 18:35:11 kmod-ide-core or kmod-usb-storage. But kmod-ata-core was forgotten; this Apr 10 18:35:11 patch fixes it. Apr 10 18:35:12 Signed-off-by: Benjamin Cama Apr 10 18:35:17 florian * r20785 /trunk/package/base-files/files/etc/hotplug2-common.rules: Apr 10 18:35:18 [package] add debugging entry to hotplug config Apr 10 18:35:18 This is useful for seeing what devices are detected by the system. Apr 10 18:35:18 Signed-off-by: Philip Prindeville Apr 10 18:35:49 [florian]: ping Apr 10 18:36:31 <[florian]> rtz2: pong Apr 10 18:37:36 lars * r20786 /trunk/target/linux/mx2/ (18 files in 10 dirs): [kernel] Add mx2 target with very basic support for the vp6500 voip phone Apr 10 18:37:39 [florian]: you remeber the problem with growing kernel with newer gcc versions? Apr 10 18:37:50 <[florian]> rtz2: yes Apr 10 18:38:53 [florian]: actually, that's not the case, the kernel is even smaller with newer versions Apr 10 18:39:04 [florian]: but the compression ration with lzma is worse Apr 10 18:39:23 ratio Apr 10 18:39:45 [florian]: I played a bit with the lzma options, it should fit now Apr 10 18:39:56 <[florian]> rtz2: great Apr 10 18:40:16 [florian]: I will prepare a patch for it Apr 10 18:40:32 [florian]: and I have also a working RC for gcc 4.5 Apr 10 18:40:59 [florian]: anyway, could you delete the current 2.6.32 stuff? Apr 10 18:41:22 it's outdated anyway, and I want to see, if I can get .32 working Apr 10 18:41:31 <[florian]> rtz2: yes, that's fine with me Apr 10 18:42:38 <[florian]> rtz2: removing just files-2.6.32 should be enough no? Apr 10 18:44:07 [florian]: should be ok Apr 10 18:44:46 florian * r20787 /trunk/target/linux/rdc/files-2.6.32/: [rdc] remove 2.6.32 files, out of sync and going to be replaced differently Apr 10 18:45:27 <[florian]> rtz2: I am away for dinner see you later Apr 10 18:45:51 [florian]: ok, thanks Apr 10 18:47:33 include/subdir.mk makes my eyes bleed. ;( Apr 10 18:52:09 cshore_: ping Apr 10 19:24:37 pong rtz2 Apr 10 19:41:58 cshore_: how far are you with your mtd fixtrx rework? Apr 10 19:44:06 I'm pretty close....I have to figure out if it's possible to do what I wanted with the imagetag though. I was going to just say a size 0 rootfs always, but brm63xx seems not to like that. jffs2 may not be possible on the devices that complain about changing CRC. I can send you want I've got so far if you want Apr 10 19:45:21 The rework is basically done, it's the brcm63xx that I'm still working on Apr 10 19:49:24 anyone here know how to use distcc? Apr 10 19:51:39 cshore_: could you send it or get it committed? Apr 10 19:51:51 cshore_: because I need a fixup for the ar525w Apr 10 19:52:09 I won't be able to work on it until later today or tomorrow Apr 10 19:54:03 jow * r20788 /trunk/package/block-extroot/Makefile: [package] block-extroot: r20784 reverted r20735, add it back (#7104) Apr 10 19:54:48 jow: what was wrong with block-extroot? Apr 10 19:54:58 nothing Apr 10 20:00:11 xMff: why the commit? Apr 10 20:00:37 because [florian] reverted a change I made earlier Apr 10 20:00:41 ah, ok Apr 10 20:02:42 I'm pleased it's so popular and I'm planning on doing some more for it (like an automagic loading of a list of packages on the extroot on the first extroot boot (rather than flash), updating sysupgrade, and LuCI support) Apr 10 20:03:59 so expect me to be bugging on IRC for commits again relatively soon Apr 10 20:04:50 I've asked thepeople to run my becoming a core dev by you guys Apr 10 20:10:29 <_trine> which firmware do i need for a wrt54gl Apr 10 20:10:53 <_trine> is it the one labled wrt54g or wrt54gs Apr 10 20:11:32 blogic * r20789 /trunk/target/linux/ (100 files in 29 dirs): [ifxmips] adss 2.6.33 kernel patches, not defult yet as linux-atm breaks on 2.6.33 Apr 10 20:56:27 <[florian]> xMff: sorry about that, I did not pay enough attention Apr 10 20:56:41 [florian]: np Apr 10 21:02:54 florian * r20790 /trunk/target/linux/malta/ (10 files in 4 dirs): [malta] create two endian-specific subtargets, as malta can run both Apr 10 21:23:01 The kernel configs need to be split manually into the generic and the other parts, right? Apr 10 21:23:19 I mean, when adding a new kernel. Apr 10 21:24:15 yes Apr 10 21:41:37 The stuff in target/linux/generic-2.6/files/ is applied to all kernels, right? How do you make sure a change there does not break anything? Apr 10 21:42:58 yes Apr 10 21:43:19 by testing it Apr 10 21:45:21 OpenWRT is wierd. Much better then OE, but still... ;) Apr 10 21:46:02 Your patches are per-version, but the files are universal.. Apr 10 21:48:39 Heh, the files directory gets synched between trunk and backfire. Would be crazy otherwise. ;) Apr 10 21:49:13 what do you mean? Apr 10 21:50:02 backfire is branched off for maintenance of the 10.03 release series, it will just receive fixes and no new targets or kernel changes (apart from bug fixes) Apr 10 21:54:09 xMff: How long ago has it been branched off? Apr 10 21:54:19 a week ago or so Apr 10 21:54:46 See, that's why there is not that much difference yet. Apr 10 21:54:54 yep Apr 10 21:54:59 it will diverge over time Apr 10 21:55:57 This approach to patch keeping makes backporting new kernels problematic. I understand that there won't be any official backports, but still.. Apr 10 21:56:45 patch keeping contrast to what? custom kernel tress? Apr 10 21:56:49 *trees Apr 10 21:57:42 No, I mean, the separation between patches and "files", which are also basically patches. Apr 10 21:58:01 ah Apr 10 21:58:17 files can be versioned Apr 10 21:58:31 files-2.6.32 takes precedence over files Apr 10 21:58:40 if you mean that Apr 10 21:58:49 Yes, I see.. Apr 10 21:59:53 I thought files-xxx are supplementary to files. Makes much more sense now. ;) Apr 11 00:04:02 nbd: ping? It looks like the recent change to package/linux-atm/Makefile in not realy valid, and breaks the build on some kernels, because arch/$(ARCH)/include is not included. The proper way would probably be to perform make install_headers during the kernel build and point the interested parties there? Apr 11 00:08:55 xl0: how did it work before that and why does it break only sometimes? Apr 11 00:11:06 rtz2: I've back-ported 2.6.31 to bf. Will see what happens in trunk soon. Anyway, pointing userspace to raw kernel headers is a bad idea, the headers need to be installed first. Apr 11 00:15:22 xl0: you have any quick and easy fix for it? Apr 11 00:15:29 The only target that uses 2.6.31 in trunk is broken. Apr 11 00:15:44 xl0: because i'm getting this error :/ Apr 11 00:15:50 for .32 Apr 11 00:16:10 Revert the changeset. Apr 11 00:16:50 It would use the kernel headers that were created during the toolchain bootstrap. Apr 11 00:17:11 xl0: https://dev.openwrt.org/changeset/20556/ ? Apr 11 00:17:25 Yep. Apr 11 00:18:00 xl0: will do, thanks Apr 11 00:19:18 nbd: What are user-visible changes in the atm headers? Maybe the right solution would be to update the kernel headers in the toolchain, or are they not backwards-compatible? Apr 11 00:20:31 If there is no other way, we could probably run install_headers during the kernel build... Apr 11 00:21:02 xl0: I still don't understand, why it works sometimes Apr 11 00:21:32 rtz2: It probablt works for older kernels. Apr 11 00:21:46 xl0: I doubt it Apr 11 00:21:56 xl0: there are a number of targets at .32 Apr 11 00:22:03 somebody would have noticed Apr 11 00:22:12 xl0: did you try to change the kernel version? Apr 11 00:22:47 rtz2: Maybe this only happens when the toolchain kernel headers version differs from the kernel version? Apr 11 00:22:56 xl0: something like that Apr 11 00:23:07 xl0: did you update from .30 to .31 or so? Apr 11 00:23:29 because I tried to update the kernel from .30 to .32 Apr 11 00:23:30 Yep, I've updated the kirkwood target to .31. Apr 11 00:23:48 xl0: ok, I will try to run make clean Apr 11 00:23:52 xl0: maybe that's enough Apr 11 00:24:31 It would probably work. Still looks like a bug to me. ;) Apr 11 00:24:46 well, it's annoying Apr 11 00:25:24 i'm not in a mood to rebuild the complete toolchain Apr 11 00:26:06 Probably nbd would be able to comment on the change when he wakes up. **** ENDING LOGGING AT Sun Apr 11 02:59:56 2010