**** BEGIN LOGGING AT Sat Aug 23 02:59:58 2014 Aug 23 03:55:06 build #742 of brcm63xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/742 Aug 23 04:01:33 build #616 of kirkwood is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/616 Aug 23 04:02:06 build #64 of brcm47xx.mips74k is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/64 Aug 23 05:19:39 build #251 of mvebu is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/251 Aug 23 05:52:30 build #517 of octeon is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/517 Aug 23 08:03:33 <_trine> nbd I am sure something is badly broken in ar71xx wifi between November 2013 and todays trunk Aug 23 08:12:11 <_trine> nbd On my Nanostation M2 I can flash backwards and forwards with the different revisions the November 2013 one gives me 20 MB/s but todays trunk with exactly the same confs gives only about 4MB/s max with exactly the same confs Aug 23 08:12:31 <_trine> this is consistent Aug 23 08:56:34 _trine: i guess it would help if you bisect to the release where this occurs Aug 23 08:57:02 "between November 2013 and trunk" ist a pretty broad timeframe Aug 23 08:57:12 like almost 1 year Aug 23 08:57:23 <_trine> heffer, but before that I need someone to take ownership of the problem Aug 23 09:07:16 <_trine> the good working revision is r38896 Aug 23 09:08:18 the problem is that the mac80211 package has some large "gaps" since it does not directly come from an upstream source Aug 23 09:08:23 <_trine> the wifi connections are significantly better than trunk Aug 23 09:09:10 I mean its stated somewhere that it is built from wireless testing but that repo is not directly used as PKG_SOURCE Aug 23 09:09:31 <_trine> plntyk, gaps or no it does seem to be an important thing to resolve Aug 23 09:10:42 yes I agree - and - I just stated that it is somewhat difficult for "normal" ppl to do bisects with a non continuous source Aug 23 09:29:38 nico r42264 packages/libs/libnetfilter-queue * libnetfilter-queue: moved to github Aug 23 09:29:39 nico r42265 packages/libs/libnetfilter-log * libnetfilter-log: moved to github Aug 23 09:29:41 nico r42266 packages/libs/libdbi-drivers * libdbi-drivers: moved to github Aug 23 09:29:43 nico r42267 packages/libs/libdbi * libdbi: moved to github Aug 23 09:29:44 nico r42268 packages/net/ulogd * ulogd: moved to github Aug 23 09:34:55 nico r42269 packages/libs/libcelt * libcelt: moved to github (abandoned) Aug 23 10:41:18 _trine: how are you testing? Aug 23 10:42:29 <_trine> I have a nanostation m2 pointing out of my bedroom window at an AP which is about 1000 metres away Aug 23 10:42:43 what is the test? Aug 23 10:43:16 <_trine> speed test Aug 23 10:43:19 <_trine> on the net Aug 23 10:43:25 which one? Aug 23 10:43:43 <_trine> and also this is consistent with the torrents I try on it Aug 23 10:43:53 <_trine> ocula Aug 23 10:44:44 you mean speedtest.net? Aug 23 10:44:57 <_trine> http://www.speedtest.net/ Aug 23 10:44:59 <_trine> yes Aug 23 10:45:28 what's stopping you from trying a revision from, say april? Aug 23 10:45:34 <_trine> russell--, I have a few nano's Aug 23 10:46:02 <_trine> previously with one I have outside I could not even connect to this AP Aug 23 10:46:30 also, by MB/s do you mean megabits-per-second? or megabytes? typically use lower case b for bits Aug 23 10:46:32 <_trine> but with the November 2013 I could Aug 23 10:46:50 <_trine> MB/s Aug 23 10:46:50 * russell-- recommends bisecting Aug 23 10:47:30 <_trine> russell--, I am not going to do anymore work until someone takes a real interest Aug 23 10:47:42 <_trine> this is in my view important Aug 23 10:47:52 no one is going to take a real interest until you've narrowed it down more Aug 23 10:48:06 <_trine> then we have an impass Aug 23 10:48:29 everyone else has gear that works, you don't ;-) Aug 23 10:48:37 <_trine> the point remains the wifi in trunk appears to be badly broken Aug 23 10:48:54 i haven't noticed any problmes Aug 23 10:49:07 maybe only "long distance" links ? Aug 23 10:49:38 <_trine> I didnt notice any problems until I tried this AP which was an AP I connected to often Aug 23 10:50:02 <_trine> I just thought at the time something had happened to this AP at that end Aug 23 10:50:24 <_trine> until I realised it was my end and it came down to the different firmwares Aug 23 10:50:58 <_trine> I can replicate this behaviour consistently Aug 23 10:51:18 is this a snapshot you downloaded or built yourself? Aug 23 10:51:48 <_trine> the only difference being that the different firmwares with exactly the same confs have wildly different download speeds Aug 23 10:51:58 <_trine> yes I built them both Aug 23 10:52:25 but you aren't willing to even do a few bisections to narrow it down? Aug 23 10:52:43 <_trine> there could/probably be a small difference between the firmware applications contained within them Aug 23 10:53:14 <_trine> russell--, I am certainly willing to do more work,, of course I am Aug 23 10:53:57 <_trine> but not if others are going to say "well I dont have this problem" which is just a head in the sand attitude Aug 23 10:54:42 if you can identify the bug or the commit where it happened, some one will look, i am confident Aug 23 10:54:54 * russell-- has done that any number of times Aug 23 10:55:00 <_trine> I do not know what is the real cause of the different wifi speeds all I can say is one firmware is vastly different to the other Aug 23 10:55:47 <_trine> I could start by giving you a list of what is installed in each firmware Aug 23 10:55:58 <_trine> I already have that Aug 23 10:56:18 a complete bug report would help Aug 23 10:56:35 <_trine> russell--, and there is another facet to this story Aug 23 10:57:50 <_trine> this difference in download speeds is not so apparent on some other AP's which is something I find a bit odd Aug 23 10:58:32 plntyk's theory might explain that Aug 23 10:58:44 <_trine> it might Aug 23 10:58:56 <_trine> but I am not sure Aug 23 11:00:32 <_trine> the other thing I have noticed is that I have to be extremely precise with how I point my nano at this AP ,, if the direction is off even a small amount the connection is virtually none existent Aug 23 11:00:36 try adding option distance to the wifi-device Aug 23 11:00:49 <_trine> russell--, I have done all that Aug 23 11:01:02 is it in your detailed bug report? Aug 23 11:01:24 <_trine> which bug report Aug 23 11:01:29 EXACTLY Aug 23 11:01:40 <_trine> I knew you were going to say that Aug 23 11:01:48 lol Aug 23 11:02:44 <_trine> anyway thats it,, until this is resolved the bug remains and I will have to stay with the November 2013 revision Aug 23 11:03:03 no, you can try april and see if it was broken then. Aug 23 11:03:31 by the time you get it narrowed down, someone will have some prayer of spotting the problem Aug 23 11:03:35 <_trine> actually as I compile the firmwares I save them in dated folders so i do have them Aug 23 11:04:19 excellent! Aug 23 11:04:27 <_trine> the trouble is there seems to be a state of denial Aug 23 11:04:28 (i do that too) Aug 23 11:05:05 it's not denial, it's "we are relying on you, there person who is seeing the problem, to narrow it down" Aug 23 11:06:06 <_trine> well first someone with some knowledge should look at what changes occured in which revision which could have affect this Aug 23 11:06:19 <_trine> affected* Aug 23 11:06:26 there are too many changes, please narrow it down. Aug 23 11:06:44 <_trine> that will say my flash from too much wear Aug 23 11:07:36 * russell-- goes to sleep Aug 23 11:07:51 <_trine> I have mentioned this previously some moths back so its not recent Aug 23 11:07:57 <_trine> months* Aug 23 11:08:51 (/me brushing teeth) in a few days, you could have identified the exact commit that caused the problem Aug 23 11:09:08 * _trine stokes russell--'s head and gently pats him back to sleep again Aug 23 11:09:48 <_trine> strokes* Aug 23 11:10:07 <_trine> oh well I suppose I will go and do something else Aug 23 12:19:28 build #157 of cns3xxx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/157 Aug 23 15:32:30 Should I bump versions of asterisk packages in release branch? There were minor issues resolved, e.g. memory leaks and several regressions. Aug 23 15:33:31 I am not sure if at this time the packages should be frozen or not. Aug 23 15:53:05 slachta: minor version bumps for bug fixes are fine Aug 23 15:53:27 you are actually encouraged to do that ;-) Aug 23 15:55:17 KanjiMonster: okay :) Aug 23 17:42:36 build #665 of ppc44x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/665 Aug 23 18:30:53 build #271 of imx6 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/271 Aug 23 19:16:15 build #676 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/676 Aug 23 19:19:21 build #634 of sibyte is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/634 Aug 23 20:15:06 build #646 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/646 **** ENDING LOGGING AT Sun Aug 24 02:59:58 2014