**** BEGIN LOGGING AT Wed Apr 13 02:59:57 2011
Apr 13 03:03:39 <builder_> build #4 of etrax is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/4
Apr 13 05:12:24 <russell--> criminy, why doesn't PrimasMike just call the ethertest dudes and ask them???
Apr 13 05:55:22 <russell--> the x86 images changed ... now a .gz?  how do you dd an image nowadays?
Apr 13 05:55:43 <russell--> oh, i suppose you can pipe from zcat to dd
Apr 13 08:36:45 <Acinonyx> gmorning
Apr 13 08:37:24 <xMff> russell--: exactly. sysupgrade handles .gz files too
Apr 13 09:25:22 <KanjiMonster> hm, who is the trac admin?
Apr 13 09:26:11 <loswillios> thepeople
Apr 13 09:27:01 <KanjiMonster> ah, ok, then I have to continue to nag him ;)
Apr 13 09:27:15 <KanjiMonster> thepeople: ping
Apr 13 09:35:45 <KanjiMonster> OutBackDingo: no updates from my side yet
Apr 13 09:42:28 <KanjiMonster> xMff: since I now have a trac account, would you mind if I do some cleaning up, i.e. closing/moving tickets (primarily backfire)?
Apr 13 09:42:52 <xMff> later
Apr 13 09:43:13 <CIA-83> loswillios * r26640 /packages/sound/pulseaudio/patches/001-no_default_64mb_alloc.patch: [packages] pulseaudio: drop dbus dependency, add back libsamplerate, allow to start on devices with <64mb ram, bump release
Apr 13 09:46:32 <loswillios> so much for git commit --amend
Apr 13 09:47:27 <CIA-83> loswillios * r26641 /packages/sound/pulseaudio/Makefile: [packages] pulseaudio: fix 26640
Apr 13 10:07:10 * russell-- converted a 5GHz batman-adv mesh from madwifi to ath5k tonight.  the SNR actually got worse, but the performance got better, because one flakey link dropped out and now everything gets relay'd over more solid links.  so packet loss went to zero(ish) but latency got a little worse too.
Apr 13 10:08:12 <loswillios> I will try ath5k on my fonera and wgt634u soon
Apr 13 10:08:30 <russell--> sometimes i get weird-clearly-incorrect signal numbers from iw wlan0 station dump
Apr 13 10:09:28 <russell--> like, the reported signal strength suddenly drop 20-30 db, but the bit rate stays the same and the packets keep getting through
Apr 13 10:30:44 <trine> cshore, yate 3.3.2 has been released but it does not compile  http://dpaste.com/531564/
Apr 13 12:29:39 <thepeople> KanjiMonster: pong (in and out)
Apr 13 12:29:57 <KanjiMonster> ah, hi
Apr 13 13:27:49 <CIA-83> jow * r26642 /trunk/tools/ipkg-utils/patches/180-add_installed_size.patch: [tools] ipkg-utils: use (g)stat instead of "du -b" to find package size, fixes Darwin compat (#9214)
Apr 13 13:28:25 <CIA-83> jow * r26643 /branches/backfire/tools/ipkg-utils/patches/180-add_installed_size.patch: [backfire] merge r26642
Apr 13 13:37:57 <CIA-83> acoul * r26644 /trunk/package/hostapd/Makefile: package/hostapd: cosmetic fix
Apr 13 13:38:50 <CIA-83> lars * r26645 /trunk/package/kernel/modules/fs.mk:
Apr 13 13:38:50 <CIA-83> kernel: revert r24160 (remove the bogus ext2/ext3 dependency on linux 2.6.30/31)
Apr 13 13:38:50 <CIA-83> For kernel versions newer then 2.6.31 the ext4 module can be used to mount
Apr 13 13:38:50 <CIA-83> ext2/3 filesystems.
Apr 13 13:38:50 <CIA-83> Building ext2/3 as modules on the other hand breaks using ext4 for mounting ext2
Apr 13 13:38:51 <CIA-83> or ext3, which breaks booting from ext2/3 on machines where the ext4 module is
Apr 13 13:38:52 <CIA-83> built into the kernel.
Apr 13 13:41:34 <KanjiMonster> xMff: or should I just give you links to easily closable tickets? ;)
Apr 13 13:44:27 <jow_laptop> KanjiMonster: I was about to go to work
Apr 13 13:44:39 <KanjiMonster> ah
Apr 13 13:44:45 <jow_laptop> KanjiMonster: you can give me the list, I'll look at closing them
Apr 13 13:56:23 <KanjiMonster> jow_laptop: these tickets can be closed or should be retargeted: http://paste.openwrt.org/kqVrd1rg/ (I saw a bunch of others that might, but those need confirmation first)
Apr 13 14:01:32 <jow_laptop> KanjiMonster: well the rtl8366s jumbo frame support is a soc limitation in most cases, sisn't it?
Apr 13 14:01:49 <jow_laptop> I mean we do not support any platfrom with rtl8366s without a limitin soc
Apr 13 14:02:43 <KanjiMonster> jow_laptop: yes and no, you could still allow jumbo frames so any lan devices can use them; e.g. if you have a nas attached that can do jumbo frames
Apr 13 14:02:54 <jow_laptop> ah hm
Apr 13 14:03:46 <jow_laptop> ok all donw
Apr 13 14:03:49 <jow_laptop> done
Apr 13 14:06:17 <KanjiMonster> I think we should move all packaging requests without patches to either features paradise or attitude adjustment (probably depending on how much sense they make) - 10.03.1 is already late enough ;)
Apr 13 14:06:32 <jow_laptop> actually we should refuse them
Apr 13 14:06:48 <jow_laptop> unless its a request for a real useful package
Apr 13 14:06:55 <jow_laptop> something like tcpdump or ipsec
Apr 13 14:07:02 <jow_laptop> which is clearly network related
Apr 13 14:08:01 <jow_laptop> I could imagine a kind of "universe" or "multiverse" feed which is maintained externally but referenced in feeds.conf, maybe commented out
Apr 13 14:08:43 <jow_laptop> so people can stage their stuff there
Apr 13 14:08:49 <KanjiMonster> good idea
Apr 13 14:09:15 <KanjiMonster> btw, the LRPng one does make sense; from what I read it seems to work for some printers where p910nd doesn't
Apr 13 14:09:56 <jow_laptop> yeah but personally I think that pacakges should be done by people using them
Apr 13 14:10:02 <jow_laptop> or at least having the means to try them
Apr 13 14:10:09 <jow_laptop> I have no printer
Apr 13 14:10:12 <KanjiMonster> yes
Apr 13 14:21:21 <stintel>  /nr 3
Apr 13 14:24:03 <KanjiMonster> https://dev.openwrt.org/ticket/8647 <- this is at most an attitude adjustment request (and not a bug in luci) - perhaps there should be a "hardware donation needed" state for hardware support tickets?
Apr 13 14:25:27 <EqUaTe> well it's just a question, they've not even tried it..
Apr 13 14:25:57 <EqUaTe> depending on what mood you're in, you could reply with "don't know. try it and let us know."
Apr 13 14:28:55 <KanjiMonster> I'm 99,9% sure it isn't supported (the mentioned rb/750 isn't either) ;)
Apr 13 14:29:26 <EqUaTe> even easier then. "No."
Apr 13 14:29:30 <EqUaTe> then resolve the ticket :P
Apr 13 14:29:54 <jow_laptop> I tend to dismiss those one-liners with a hint to the devel list and or the forum
Apr 13 14:30:11 <KanjiMonster> heh
Apr 13 14:30:17 <EqUaTe> i'd reject it as 'not a defect'
Apr 13 14:30:38 <EqUaTe> but then things like that do bring out my inner BOFH
Apr 13 14:30:49 <EqUaTe> (not that i try very hard to keep it hidden)
Apr 13 14:30:57 <KanjiMonster> https://dev.openwrt.org/ticket/8719 <- this one seems to have been verified as "fixed" by the reporter, so it can be closed
Apr 13 14:31:13 <jow_laptop> no need to insult the creators of such stupid tickets
Apr 13 14:31:14 <_trine> the testosterone flows
Apr 13 14:31:40 <jow_laptop> but a simple invalid + "please go bla this is no support channel" response
Apr 13 14:35:12 <jow_laptop> don't know whether you looked into the dd-wrt timeline yet but they tend to be really unfriendly
Apr 13 14:35:25 <jow_laptop> almost annoyed by any report :P
Apr 13 14:35:37 <jow_laptop> but then they have a lower user education standard I believe
Apr 13 14:45:00 <KanjiMonster> https://dev.openwrt.org/ticket/8598 <- I can't find any report of bcm47xx ever working for it (only reports that it doesn't); brcm-2.4 did seem to work for 8.09.2 though (according to some thread on the forms ;)
Apr 13 14:45:08 <builder_> build #7 of s3c24xx is complete: Failure [failed compile_10]  Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/7
Apr 13 14:45:38 <jow_laptop> missing serial flash support maybe?
Apr 13 14:46:02 <jow_laptop> sflash was added to brcm-2.4 shortly before it was eol'd so it supported a few more devices
Apr 13 14:48:13 <KanjiMonster> possibly, but I saw some boot logs suggesting otherwise
Apr 13 14:48:52 <KanjiMonster> heh, I totally forgot that I wanted to finish cleaning up and post the sflash support for brcm47xx
Apr 13 14:48:59 <jow_laptop> :)
Apr 13 14:49:58 <KanjiMonster> still not mainline ready, but definitely cleaner code than the one attached in some of the tickets ;)
Apr 13 14:50:50 <KanjiMonster> let's see where I hid them in the filesystem...
Apr 13 15:01:00 <builder_> build #4 of mpc52xx is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/4
Apr 13 15:07:12 <ermo> This is really strange. In backfire (svn up'ed today) I still see the missing memory issue with my wl500gP, whereas with trunk (with the same configuration) it has disappeared.
Apr 13 15:54:04 <mazilo> trine: I just PMed you.
Apr 13 15:57:45 <CIA-83> jow * r26646 /packages/utils/hd-idle/Makefile: [packages] hd-idle: readd PKG_BUILD_DIR
Apr 13 16:43:13 <CIA-83> acoul * r26647 /trunk/target/linux/adm5120/patches-2.6.38/ (11 files): linux/adm5120: add 2.6.38 preliminary support
Apr 13 16:48:36 <CIA-83> acoul * r26648 /trunk/target/linux/adm5120/ (router_be/config-2.6.38 router_le/config-2.6.38): linux/adm5120: preliminary 2.6.38 config options
Apr 13 16:57:56 <philipp64|laptop> where in the Make machinery do patches get applied?
Apr 13 16:59:36 <xMff> include/quilt.mk
Apr 13 17:25:04 <philipp64|laptop> xMff: should scripts/kernel_patch.sh include '-N' ?
Apr 13 17:25:18 <xMff> context?
Apr 13 17:25:34 <philipp64|laptop> errr... patch-kernel.sh rather...
Apr 13 17:25:52 <xMff> no it shouldn't
Apr 13 17:25:59 <xMff> it should fail straightly if something does not fit
Apr 13 17:26:48 <philipp64|laptop> let's say I add a patch (say patches-2.6.37/282-solos-debug_skbuff.patch)... and then a future version of the kernel already has this applied...
Apr 13 17:27:02 <philipp64|laptop> it seems to me that idempotent patching should be ok.
Apr 13 17:27:23 <philipp64|laptop> it's not that the patch "doesn't fit"... it's already been fitted. :-)
Apr 13 17:27:47 <xMff> yeah and then nobody notices and you aggregate patch-rot in the svn
Apr 13 17:28:38 <philipp64|laptop> that assumes that you'd never want to back up and build an older micro-version...
Apr 13 17:29:07 <philipp64|laptop> you might want to back up from 37.5 to 37.2, for instance, to check a regression, etc.
Apr 13 17:29:08 <xMff> ?
Apr 13 17:29:35 <nbd> well, there's this thing called version control ;)
Apr 13 17:30:07 <nbd> i heard it can be used for something like that...
Apr 13 17:30:19 <philipp64|laptop> yeah, I hate reverting individual directories like target/ though... that has problems of its own.
Apr 13 17:30:27 <nbd> then revert the full openwrt version
Apr 13 17:30:37 <nbd> if it's just for checking regressions, it should be enough
Apr 13 17:31:46 <xMff> maybe one could implement a PATCH_OPTS env var or something
Apr 13 17:31:58 <nbd> i understand your point, but leaving patches that no longer apply in the tree cause unnecessary confusion for regular maintenance of the patch tree
Apr 13 17:32:18 <nbd> whereas the need for compiling a new version of openwrt with an old version of the patches is rare
Apr 13 17:32:24 <nbd> in fact so rare that i never needed it myself
Apr 13 17:33:24 <nbd> so introducing confusion into a normal workflow in order to make something that's almost never needed just a little easier is unacceptable.
Apr 13 17:41:22 <CIA-83> acinonyx * r26649 /packages/utils/pciutils/Makefile: [packages] pciutils: Do not automatically update PCI IDs on real system
Apr 13 17:41:28 <CIA-83> acinonyx * r26650 /packages/utils/usbutils/Makefile: [packages] usbutils: Do not automatically update USB IDs on real system
Apr 13 17:45:49 <philipp64|laptop> nbd: well, we could have a "make" target that would suppress the -N option and reports the patches that fail to apply... then just run that occasionally.
Apr 13 17:46:25 <nbd> i disagree
Apr 13 17:46:28 <nbd> patches are managed using quilt
Apr 13 17:46:37 <nbd> and patches are maintained in a way that all of them should apply cleanly
Apr 13 17:48:53 <nbd> so far i see no significant advantage to adding this, yet several annoying disadvantages
Apr 13 18:16:49 <_trine> KanjiMonster, znc is now up to 0.098
Apr 13 18:17:26 <_trine> cshore, yate is now up to 3.3.2
Apr 13 18:17:54 * _trine gets his whip out 
Apr 13 18:18:16 <_trine> ;)
Apr 13 18:27:06 <CIA-83> jogo * r26651 /packages/net/znc/ (3 files in 2 dirs): (log message trimmed)
Apr 13 18:27:06 <CIA-83> ZNC: Update to 0.098 and minor fixes
Apr 13 18:27:06 <CIA-83> * Update ZNC to latest stable
Apr 13 18:27:06 <CIA-83> * Update download URI to new location
Apr 13 18:27:06 <CIA-83> * Add a fix for building webadmin with uClibc++ and enable it
Apr 13 18:27:06 <CIA-83> * Reduce build time slightly skipping the man target
Apr 13 18:27:06 <CIA-83> * Add myself as maintainer
Apr 13 18:27:15 <KanjiMonster> _trine: I know ;)
Apr 13 18:27:30 <_trine> :)
Apr 13 18:28:32 <_trine> theres nothing better in the world than a new brush
Apr 13 18:28:50 <_trine> service guaranteed
Apr 13 18:29:13 <KanjiMonster> Olipro: ping
Apr 13 19:02:52 <builder_> build #5 of ps3 is complete: Failure [failed compile_2]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/5
Apr 13 19:02:53 <builder_> build #5 of ramips is complete: Failure [failed compile_2]  Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/5
Apr 13 19:13:29 <builder_> build #5 of pxcab is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/5
Apr 13 19:15:56 <mazilo> trine: R U there?
Apr 13 19:16:29 <trine> ya
Apr 13 19:19:12 <trine> were you just checking ? ;)
Apr 13 19:20:16 <mazilo> Nope. But, I was awaiting for yate-3.3.2 compilation to finish. Now, it compiled successfully, except faxchan module.
Apr 13 19:21:29 <trine> oh
Apr 13 19:21:49 <trine> mine will not compile tonegen
Apr 13 19:22:24 <trine> what did you do to get that to compile
Apr 13 19:22:57 <mazilo> If I enable faxchan module, it crashes on packaging stage with an error message of not able to locate faxchan.yate module.
Apr 13 19:23:23 <trine> but how did you get tonegen to compile
Apr 13 19:25:36 <xMff> KanjiMonster: do you have pending changes on znc?
Apr 13 19:25:38 <mazilo> Was it last night or this morning you sent me a link to show the compilation error? I had the same compilation error, too. But, now it looks like the error had gone, except the faxchan module.
Apr 13 19:26:13 <KanjiMonster> xMff: yes, I was hoping for comments by Olipro
Apr 13 19:26:45 <xMff> I have a fix for the config depends based on the svn version from a few minutes ago
Apr 13 19:26:48 <mazilo> On top of that, I have amrnb lib package (only needed if you want to include amrnb codec).
Apr 13 19:27:05 <mazilo> xMff: Thank.
Apr 13 19:27:23 <KanjiMonster> xMff: ah, shouldn't be a problem; my local changes are only for the init script (and uci config)
Apr 13 19:27:35 <xMff> touch /home/jow/devel/openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.32/znc-0.098/.configured_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
Apr 13 19:27:48 <KanjiMonster> oh, looks good :)
Apr 13 19:27:48 <xMff> oops
Apr 13 19:27:54 <xMff> yes, indeed
Apr 13 19:28:44 <xMff> sicne the Build/Compile is now defined after all the modules we could think about assembling it dynamically
Apr 13 19:28:59 <xMff> to save build time
Apr 13 19:29:42 <xMff> did you investigate how the modules to build can be communicated to the upstream make process?
Apr 13 19:29:57 <xMff> is it an env var or something?
Apr 13 19:32:11 <KanjiMonster> make -C $(PKG_BUILD_DIR)/modules $modulename is the "official" way
Apr 13 19:32:29 <xMff> ah ok
Apr 13 19:32:54 <KanjiMonster> (there's extra logic in the modules/Makefile to catch extra modules)
Apr 13 19:33:38 <xMff> let's see
Apr 13 19:35:14 <KanjiMonster> so the same way as the buildModules are called I can do a $(foreach ,m, ..., $(if $CONFIG_PACKAGE_znc-mod-$(m),$(call Build/Compile/$(m))) or something like that (with a Build/Compile/$(1) defined in the plugin template that just makes the appropriate make call)
Apr 13 19:36:53 <xMff> is it possible to pass multiple modules to make -C modules ... ?
Apr 13 19:39:22 <KanjiMonster> I don't see why not
Apr 13 19:39:51 <KanjiMonster> actually, yes, thats the way all modules are built
Apr 13 19:40:24 <xMff> man the C++ warnings are so spammy, one can't see the actual commandlines
Apr 13 19:40:43 <KanjiMonster> (all: $(TARGETS), where $TARGETS = (all module names) in the modules makefile)
Apr 13 19:44:20 <xMff> I think I got it
Apr 13 19:44:38 <KanjiMonster> cool
Apr 13 19:45:59 <KanjiMonster> hrm, is there an less demanding way to create an git-svn checkout than retrieving *all* old revisions?
Apr 13 19:46:05 <xMff> http://luci.subsignal.org/~jow/znc.patch
Apr 13 19:47:23 <xMff> hm no
Apr 13 19:47:34 <xMff> the passing of the module names seems to have no effect
Apr 13 19:47:52 <xMff> probably not passed on by the Build/Compile/Default macro
Apr 13 19:49:53 <KanjiMonster> I think building individual modules only work with a make call in $(PKG_BUILD_DIR/modules, not in the source root folder
Apr 13 19:50:01 <xMff> CXXFLAGS=[...] make -j1 -C /home/jow/devel/openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.32/znc-0.098/. AR=[...] modules awaynick blockuser
Apr 13 19:50:17 <xMff> ah ok
Apr 13 19:50:38 <xMff> so  $(MAKE) -C $(PKG_BUILD_DIR)/modules foo bar baz
Apr 13 19:50:44 <KanjiMonster> yes
Apr 13 19:56:13 <KanjiMonster> xMff: note that you still have to provide the extra/ if its an module in the extra directory
Apr 13 20:03:02 <xMff> modules/extra/ ?
Apr 13 20:05:30 <KanjiMonster> xMff: -C <bla> foo bar extra/baz
Apr 13 20:05:42 <xMff> ah
Apr 13 20:13:43 <xMff> ok
Apr 13 20:13:47 <xMff> new patch, same location
Apr 13 20:18:47 <xMff> hm
Apr 13 20:19:01 <KanjiMonster> xMff: you need to build at least the droproot module; it's packaged and used by the znc package itself
Apr 13 20:19:01 <xMff> with make -C modules/ foo it fails to find its own headers
Apr 13 20:20:31 <xMff> ok updated the patch
Apr 13 20:23:33 <xMff> hmpf
Apr 13 20:23:36 <xMff> extra/droproot
Apr 13 20:24:20 <KanjiMonster> right, sorry
Apr 13 20:24:32 <xMff> np ;)
Apr 13 20:24:48 <xMff> now it also looks like a s/-/_/ is needed for the plugin targets
Apr 13 20:31:52 <KanjiMonster> ah, yes
Apr 13 20:32:52 <xMff> grr
Apr 13 20:33:10 <xMff> apparently the module makefile does not look in ../ for headers
Apr 13 20:33:22 <xMff> so I have to inject -I$(PKG_BUILD_DIR) somehow
Apr 13 20:37:44 <xMff> hm no it does
Apr 13 20:37:47 <xMff> I don't get it
Apr 13 20:44:09 <xMff> ah hmm
Apr 13 20:44:17 <xMff> its   make -C modules extra/foo.so
Apr 13 20:46:14 <KanjiMonster> oh, oops. my bad
Apr 13 20:48:05 <KanjiMonster> I remember doing the same mistake when I tried getting it to build the individual plugins
Apr 13 20:49:04 <builder_> build #5 of uml is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/5
Apr 13 20:51:55 <xMff> almost... now only the install stage is b0rken
Apr 13 20:52:31 <Acinonyx> heh, what are you trying to do?
Apr 13 20:52:42 <xMff> optimize the znc build
Apr 13 20:53:02 <xMff> I already fixed the config depends, now I tackle conditional compilation of addons
Apr 13 20:53:58 <builder_> build #6 of x86 is complete: Failure [failed compile_1]  Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/6
Apr 13 20:55:43 <Acinonyx> cool
Apr 13 20:55:52 <xMff> KanjiMonster: ok, updated the patch again
Apr 13 20:55:56 <xMff> KanjiMonster: it works nicely now
Apr 13 20:56:22 <Acinonyx> I like the ", := ," in the Makefile
Apr 13 20:56:25 <Acinonyx> it's like a smiley
Apr 13 20:57:57 <KanjiMonster> xMff: cool
Apr 13 21:14:25 <trine> was anything at all agreed from the head banging session we had last week on here
Apr 13 21:15:03 <trine> the meeting gregers organised
Apr 13 21:15:45 <xMff> patchwork, patches to devel list
Apr 13 21:15:59 <xMff> seemed to work out okay, a great deal of patches have been applied
Apr 13 21:19:39 <trine> are there any minutes of the meeting
Apr 13 21:24:40 <KanjiMonster> glp said he wanted to post a summary
Apr 13 21:26:31 <trine> that would be useful
Apr 13 21:36:46 <philipp64|laptop> hmm... anyone have a look at this? http://tksite.gotdns.org:8010/builders/x86/builds/6/steps/compile_1/logs/stdio
Apr 13 21:37:33 <philipp64|laptop> it looks like either a regression was introduced (i.e. looking for the host's version of grub) or else failing to use the correct path to the one built for this purpose...
Apr 13 21:39:01 <xMff> no regression
Apr 13 21:39:06 <xMff> a badly set up slave
Apr 13 22:08:27 <CIA-83> luka * r26652 /packages/ (13 files in 4 dirs): upgrade libtorrent and rtorrent
Apr 13 22:15:30 <CIA-83> luka * r26653 /packages/net/rtorrent/patches/120-fix-ncurses.patch: add rtorrent ncurses patch
Apr 13 22:21:25 <builder_> build #5 of ar7 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/5
Apr 13 22:22:01 <CIA-83> luka * r26654 /packages/utils/hdparm/Makefile: upgrade hdparm
Apr 13 22:26:10 <CIA-83> luka * r26655 /packages/utils/hd-idle/Makefile: minor update hd-idle
Apr 13 22:28:00 * russell-- seeing a 16 dB difference in "signal avg" between a wistron cm9 (ath5k) and a ubiquiti bullet m5hp (ath9k)
Apr 13 22:31:37 <russell--> worst case from spec sheet should be 12 dB (with cm9 at highest tx rate and bullet-m5hp at lowest)
Apr 13 22:32:47 * russell-- prepared to blame it on unreliable measurement in drivers
Apr 13 22:32:58 <Acinonyx> have you set txpower manually?
Apr 13 22:33:20 <nbd> russell--: which one shows higher signal strength?
Apr 13 22:33:34 <russell--> the cm9
Apr 13 22:33:47 <Acinonyx> hmm
Apr 13 22:33:48 <russell--> shows more received signal strenght
Apr 13 22:34:02 <Acinonyx> oh
Apr 13 22:34:04 <russell--> ~circa 50 dBm
Apr 13 22:34:17 <russell--> while the bullet show about -68 dB
Apr 13 22:34:29 <russell--> cm9 shows -50 dB
Apr 13 22:34:38 <russell--> bullet shows -68 dB
Apr 13 22:34:46 <nbd> what's the noise floor on both?
Apr 13 22:34:48 <russell--> in iw wlan0 station dump
Apr 13 22:34:53 <nbd> in iw wlan0 survey dump
Apr 13 22:35:26 <russell--> bullet shows noise:-116 dBm
Apr 13 22:35:51 <russell--> cm9 shows noise:-101 dBm
Apr 13 22:36:29 <Acinonyx> is this possible?
Apr 13 22:36:32 <russell--> lol
Apr 13 22:36:42 <russell--> that was what i was thinking
Apr 13 22:37:50 <russell--> would be nice to know how reliable those numbers were ... or rather to be able to believe them.
Apr 13 22:38:31 <russell--> Acinonyx: i have not set any txpower on either end
Apr 13 22:40:48 <Acinonyx> well, -116dBm is surely wrong
Apr 13 22:41:10 <Acinonyx> -101 is almost wrong
Apr 13 22:41:29 <russell--> it is one of the fancy new m5hp's ... maybe they are magical!
Apr 13 22:42:17 <russell--> i just ordered two more, in order to embue myself with their mystical powers
Apr 13 22:42:40 <Acinonyx> lol
Apr 13 22:43:19 <russell--> because of the imbalance in the tx powers, i am planning to replace the cm9 as soon as practical
Apr 13 22:43:25 <nbd> actually, -116 is not wrong
Apr 13 22:43:30 <russell--> sweet!
Apr 13 22:43:45 <nbd> it matches the documented sane NF values for the chip used in the bullet m5hp
Apr 13 22:45:00 <nbd> so while -68 seems low, it's still an snr of 48, which is certainly not bad
Apr 13 22:45:09 <Acinonyx> IIRC, -101dBm is theoretical noise floor on 20MHz channel on room temperature
Apr 13 22:45:25 <nbd> the difference probably originates from the different measurement methods
Apr 13 22:45:48 <russell--> 52.1°F here atm
Apr 13 22:45:56 <russell--> about 11C
Apr 13 22:46:07 <russell--> outside, probably a little warmer inside the box
Apr 13 22:46:50 <russell--> in theory the same antennas and cable attenuation should be the same in both rx and tx directions, you'd think
Apr 13 22:47:21 <russell--> assuming the attenuation is linear with power
Apr 13 22:47:29 <Acinonyx> nbd: how do they come up with -116dBm in the datasheet?
Apr 13 22:48:00 <Acinonyx> on which bandwidth
Apr 13 22:48:02 <Acinonyx> ?
Apr 13 22:48:06 <Acinonyx> 1MHz?
Apr 13 22:48:24 <nbd> no idea how this is measured
Apr 13 22:49:32 * russell-- considering moving this discussion to #linux-wireless
Apr 13 22:51:40 <Acinonyx> http://en.wikipedia.org/wiki/Johnson–Nyquist_noise
Apr 13 23:35:21 <RealOpty> whois George Kashperko ?
Apr 13 23:44:45 <philipp64|laptop> xMff: sorry, I left a file out of the patch that went in as r26617: http://fpaste.org/5SZt/
Apr 13 23:45:08 <philipp64|laptop> nothing major... just updating a comment.
Apr 13 23:46:05 <russell--> RealOpty: google says he is someone who as posted to lkml recently
Apr 13 23:47:30 <KanjiMonster> RealOpty: from my experience a very, ugh, enthusiastic person trying to get the newer style broadcoms supported - sometimes struggling with the english language
Apr 13 23:48:09 <RealOpty> okay ty
Apr 13 23:48:18 <RealOpty> KanjiMonster, does he come on IRC any?
Apr 13 23:49:31 <KanjiMonster> not that I know of; my only experience is reading him on -devel and on trac (and linux-wireless)
Apr 13 23:50:54 <RealOpty> same
Apr 13 23:52:09 <RealOpty> needed to ask him about his SSB patch for an ASUS router. its brcm47xx based so it should possibly fix my issue
Apr 13 23:54:05 <KanjiMonster> which one?
Apr 13 23:54:32 <RealOpty> ASUS RT-N16
Apr 13 23:55:18 <KanjiMonster> afaik all his SSB patches were to support the new style broadcoms which use the AMBA/AXI backplane, which is a replacement for the older SSB
Apr 13 23:56:04 <KanjiMonster> so unless you do have one of the newer broadcoms, these patches won't probably do anything for you
Apr 13 23:56:16 <KanjiMonster> btw, what's your issue?
Apr 13 23:57:47 <RealOpty> from what i remember is, when i did lspci nothing showed up
Apr 13 23:57:59 <RealOpty> was trying to get my wifi working on this router
Apr 13 23:58:00 <RealOpty> http://wiki.openwrt.org/toh/netgear/wnr834b?s[]=wnr834b
Apr 13 23:58:14 <RealOpty> its a version 2
Apr 13 23:58:29 <RealOpty> brcm4321 wireless b/g/n
Apr 13 23:58:56 <RealOpty> that was 8 months ago. time to make a new build and test again
Apr 14 00:00:09 <RealOpty> hmm i might be able to save time and use a snapshot :/
Apr 14 00:01:08 <KanjiMonster> I think I read about your problem (was it the ticket where it shows up on tomato and doesn't on openwrt or something like that?)
Apr 14 00:02:16 <RealOpty> dont think thats the one. wifi works on 2.4 kernel but thats dd-wrt
Apr 14 00:03:24 <KanjiMonster> ah, right, different router but perhaps same problem? -> https://dev.openwrt.org/ticket/8861
Apr 14 00:04:46 <philipp64|laptop> can someone apply this patch please? http://fpaste.org/xpyN/ ... it's trivial.  missing x86 symbols.
Apr 14 00:05:44 <RealOpty> yeah that looks just like the issue i was havin
Apr 14 00:06:38 <KanjiMonster> (also same wifi)
Apr 14 00:07:20 <RealOpty> ^- just noticed that heh
Apr 14 00:08:26 <KanjiMonster> RealOpty: it's probably okay if you reopen the issue (I guess florian was a bit too quick with closing it)
Apr 14 00:09:04 <RealOpty> indeed
Apr 14 00:09:14 <RealOpty> i dont think i ever made a ticket about the wifi
Apr 14 00:09:47 <RealOpty> ill just reopen this instead of making a dupe
Apr 14 00:09:58 <KanjiMonster> :)
Apr 14 01:38:45 <neutronscott> usb porting wizard -- whats this mean to you -- http://pastebin.com/raw.php?i=8Bk83VSq
Apr 14 02:02:29 <builder_> build #4 of adm5120 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/4
Apr 14 02:29:18 <neutronscott> dnetc v2.9109-518-CFR-11022619 for Linux (Linux 2.6.36.4).
Apr 14 02:29:28 <neutronscott> [Jan 01 02:22:16 UTC] Automatic processor type detection did not recognize the processor (tag: "MIPS 4Kc V0.11")
Apr 14 02:29:31 <neutronscott> lolz
Apr 14 02:41:34 * philipp64|laptop decides he can't put off writing the leds-geos module any longer...
**** ENDING LOGGING AT Thu Apr 14 02:59:58 2011