**** BEGIN LOGGING AT Tue Feb 26 02:59:58 2013
Feb 26 03:55:37 <3JTAANC26> build #201 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/201
Feb 26 09:09:57 <fborges> hi, is there a way to mark a package as conflicting with another?
Feb 26 09:39:23 <dape8708> hello, svn.luci.subsignal.org seems down..
Feb 26 11:20:24 <stintel> dape8708: works for me.. still have problems connecting ?
Feb 26 11:22:27 <dape8708> stintel, works okay now, thanks for pinging me
Feb 26 11:24:22 <stintel> np, I just read it
Feb 26 11:27:19 <zaridan1> can anyone create a profile for d-link dir-632?
Feb 26 12:43:17 <Guest73287> cyrus r35803 trunk/package/network/ ipv6/6relayd/files/6relayd.init ipv6/6relayd/files/6relayd.config ipv6/6relayd/Makefile
Feb 26 12:43:17 <Guest73287> 6relayd: compatibility with broken IPv6 devices
Feb 26 12:43:17 <Guest73287> * Announce ULA as deprecated if other addresses are available
Feb 26 12:43:17 <Guest73287> * Allow the announced DNS-server to be overwritten
Feb 26 12:51:11 <Guest73287> cyrus r35804 trunk/package/network/ ipv6/6relayd/files/6relayd.init ipv6/6relayd/Makefile * 6relayd: Fix config behaviour for rewrite_dns_addr option
Feb 26 12:59:58 <zaridan1> Can anyone help me? error while booting kernel (can't see mtd partition): [    0.300000] VFS: Cannot open root device "31:03" or unknown-block(31,3): error -6  : https://dev.openwrt.org/ticket/13069
Feb 26 13:00:30 <zaridan1> DIR-632, compilate by default
Feb 26 13:00:54 <zaridan1> image: openwrt-generic-uimage-lzma.bin
Feb 26 14:31:42 <Guest73287> luka r35805 trunk/toolchain/ (18 files in 2 dirs) * [toolchain] gcc: remove support for 4.6.2
Feb 26 15:09:32 <zaridan> How to create profile for ar71xx in trunk?
Feb 26 15:14:51 <Guest73287> nbd r35806 trunk/package/mac80211/patches/ 300-pending_work.patch 603-rt2x00-introduce-rt2x00eeprom.patch * rt2x00: prevent device probe errors with CONFIG_MAC80211_MESH disabled (#13080)
Feb 26 15:27:29 <dape8708> nbd, ping pls
Feb 26 15:27:41 <nbd> pong
Feb 26 15:27:57 <dape8708> nbd, thanks a lot for fixing wireless few minutes ago
Feb 26 15:28:10 <dape8708> but the old lockup after reboot came back
Feb 26 15:28:26 <nbd> i don't know anything about that
Feb 26 15:28:56 <dape8708> well, as i stated in the ticket this dlink dir 615 H1 reboots fine 1 one 5 times when it doesnt locks right after bridge setup stuff
Feb 26 15:29:26 <dape8708> with the previous bug for mesh it rebooted absolutely awesome (without wireless) like 5 times, with latest trunk with your fix it crashed
Feb 26 15:29:55 <dape8708> right now its frozen after "br-lan: port 1(eth0.1) entered forwarding state"
Feb 26 15:32:40 <dape8708> hmm, seems it rebooted itself few seconds ago, now it froze at http://pastebin.com/P20yRR0C
Feb 26 15:33:55 <dape8708> rebooted again, now its hanging at "br-lan: port 1(eth0.1) entered forwarding state"
Feb 26 15:37:00 <nbd> somebody else will have to debug this, i don't even have hw to test it on, nor do i know much about rt2x00
Feb 26 15:37:29 <dape8708> sure, thanks for the previous fast fix!
Feb 26 15:38:22 <nbd> maybe ask on the openwrt list, cc the rt2x00 list
Feb 26 15:38:35 <nbd> or try enabling lockdep
Feb 26 15:38:39 <nbd> maybe it's a soft lockup
Feb 26 15:39:09 <dape8708> this are wireless, network and system config files from safe mode: http://pastebin.com/4tLUnwcu
Feb 26 15:39:21 * dape8708 quite dumb and illetterate today
Feb 26 15:40:23 <dape8708> i think i will go home, 9 hours of office work is enough, i'll post to the list if i manage to stay awake at home, maybe dangole sees it :P
Feb 26 15:49:56 <dape8708> maybe some kind of race condition, after resetting files, rebooted okay , wlan0 was quite late, i think it got ipv6 via wan6 and few seconds after that the wireless joined the bridge..
Feb 26 16:16:51 <Guest73287> luka r35807 trunk/toolchain/ (5 files in 5 dirs) * [toolchain] gcc: don't build documentation
Feb 26 16:40:12 <Guest73287> florian r35808 trunk/toolchain/ (32 files in 5 dirs) * toolchain/gcc: refresh patches
Feb 26 16:40:17 <Guest73287> florian r35809 trunk/package/devel/gdb/Makefile * gdb: do not depend on libthread-db when using musl libc
Feb 26 16:40:21 <Guest73287> florian r35810 trunk/package/toolchain/Makefile * toolchain: mark unavailable packages for musl libc
Feb 26 16:40:26 <Guest73287> florian r35811 trunk/package/libs/ncurses/patches/200-fix_missing_include.patch * ncurses: fix build with musl libc toolchains
Feb 26 16:40:30 <Guest73287> florian r35812 trunk/toolchain/ (13 files in 4 dirs) * toolchain/binutils: refresh patches
Feb 26 16:40:35 <Guest73287> florian r35813 trunk/toolchain/binutils/Makefile * toolchain/binutils: fix 2.19.1 MD5 sum
Feb 26 16:40:39 <Guest73287> florian r35814 trunk/toolchain/binutils/patches/2.23.1/200-musl.patch * toolchain/binutils: add musl libc config.sub patch to 2.23.1
Feb 26 16:40:46 <Guest73287> florian r35815 trunk/toolchain/ (7 files in 2 dirs) * toolchain/musl: add support for 0.9.9
Feb 26 16:52:55 <Guest73287> florian r35816 trunk/toolchain/binutils/Makefile * toolchain/binutils: fix partial MD5 sum from r35813
Feb 26 17:48:55 <Pteridium> Does anybody know if somebody is trying to port the bcm33xx?
Feb 26 17:53:35 <Pteridium> Or if there is a project for this SoC's. I haven't found nothing.
Feb 26 18:16:38 <Zajec> i've added target/linux/generic/patches-3.8/027-bcma-ignore-extra-GMAC-cores-on-BCM4706.patch to my OpenWrt directory
Feb 26 18:16:41 <jwendell> hi folks. why dlink's original firmware allows to set an 'automatic' channel and openwrt doesn't?
Feb 26 18:16:54 <Zajec> run "make V=s" but it looks like OpenWrt bulding system didn't notice that patch
Feb 26 18:16:59 <jwendell> is it some proprietary code?
Feb 26 18:16:59 <Zajec> why is that?
Feb 26 18:17:47 <stintel> Zajec: run make/target/linux clean first ?
Feb 26 18:17:53 <Zajec> sintax: ok
Feb 26 18:17:56 <stintel> :>
Feb 26 18:32:06 <KanjiMonster> Zajec: only kernel version changes trigger a re-extraction, for anything else you have to manually clean
Feb 26 19:45:58 <stintel> if iw survey shows noise -80dBm, that's bad ?
Feb 26 20:03:16 <3JTAANC26> build #181 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/181
Feb 26 20:05:35 <3JTAANC26> build #181 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/181
Feb 26 20:06:06 <Guest73287> luka r35817 branches/attitude_adjustment/toolchain/gcc/patches/ (5 files in 5 dirs) * gcc: don't build documentation
Feb 26 20:38:58 <3JTAANC26> build #186 of uml is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/186
Feb 26 21:13:44 <noz> Running r35574 on a WRTSL54GS, I'm getting lots of problems connecting wireless from a MacBook. Sometimes it works for a good while, at other time it drops out very quickly with "deauthenticated due to local deauth request". Any tips to get more information?
Feb 26 21:14:59 <3JTAANC26> build #183 of x86 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/183
Feb 26 21:35:24 <russell--> noz, /me vaguely recalls issues with aggressive power saving on mac's
Feb 26 21:35:42 * russell-- might be completely off rocker
Feb 26 21:40:29 <noz> russell--: That's interesting. I don't think it's that, but it's worth considering
Feb 26 21:41:15 <noz> Of course, whenever I try, it works, and whenever my wife tries, the problems happen! Still it's logged, so she isn't making it up :)
Feb 26 21:49:30 <Guest73287> luka r35818 trunk/ tools/Makefile tools/mklibs/patches/001-compile.patch tools/mklibs/Makefile * [tools] mklibs: upgrade to 0.1.35
Feb 26 21:53:17 <Guest73287> nbd r35819 trunk/package/mac80211/patches/ 300-pending_work.patch 540-mac80211_optimize_mcs_rate_mask.patch
Feb 26 21:53:17 <Guest73287> mac80211: fix sending probe requests in client mode, fixes connecting to hidden networks (#13056)
Feb 26 22:17:04 <3JTAANC26> build #171 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/171
Feb 26 22:21:31 <russell--> nbd: did you see my observation about sta+ap, where ap goes away when sta is in psk2 mode? ... works when sta is encryption=none, on ar2315
Feb 26 22:34:54 <nbd> russell--: no, didn't see it
Feb 26 22:35:12 <nbd> when/where did you describe it?
Feb 26 22:36:23 <russell--> oh, just in the channel, about 14-16 hours ago
Feb 26 22:36:49 * russell-- expected it to work, after encyrption=none had worked, was surprised that it didn't
Feb 26 22:37:08 <nbd> which version did you try?
Feb 26 22:37:09 <russell--> the ap-mode interface showed DOWN, ifconfig up didn't help
Feb 26 22:37:15 <russell--> something recent
Feb 26 22:37:26 <nbd> either way, it's time to upgrade
Feb 26 22:37:27 <nbd> ;)
Feb 26 22:37:35 <nbd> committed something today that fixes some client mode stability issues
Feb 26 22:37:35 <russell--> i don't have the device but it was built within the last week or so
Feb 26 22:37:47 <russell--> will do some more testing
Feb 26 22:38:19 <russell--> awesome!
Feb 26 22:38:40 <russell--> client mode was actually working, just killed ap-mode interface
Feb 26 23:28:15 <stintel> jow_laptop: ping ?
Feb 26 23:28:33 <jow_laptop> stintel: pong
Feb 26 23:29:06 <stintel> jow_laptop: you predicted it, and here I am :P what do you think about http://bpaste.net/show/79569/ ?
Feb 26 23:30:10 <jow_laptop> stintel: yes, I'll add something like this in the next few days
Feb 26 23:30:19 <stintel> ok good to know
Feb 26 23:30:44 <stintel> if I ever come up with a better idea, I'll ping again :)
Feb 26 23:31:05 <stintel> but my other ideas were flawed
Feb 26 23:31:58 <stintel> setting policies to DROP is a recipe for creating bricks, even if it's only for a short time to block new connections to be tracked
Feb 26 23:32:22 <stintel> s/block/prevent/
Feb 26 23:33:27 <jow_laptop> I don't follow
Feb 26 23:33:31 <stintel> oh sorry
Feb 26 23:33:49 <stintel> 25|09:02:25< stintel> how about setting default policy to DROP at the beginning of the firewall restart and set it back to ACCEPT when all rules are added ?
Feb 26 23:33:52 <stintel> 25|09:03:08< stintel> sounds dangerous though
Feb 26 23:33:53 <jow_laptop> my irssi got terminated due to a server reboot so I don't have any backlog atm
Feb 26 23:34:43 <stintel> for me having 53 etc open doesn't even matter as I have a cripled connection anyway. ISP drops < 1024 incoming, except ident
Feb 26 23:35:17 <jow_laptop> yeah, policy drop first, then rebuild rules is dangerous if the start step fails for some reason
Feb 26 23:35:44 <jow_laptop> e.g. because the config is broken
Feb 26 23:35:46 <stintel> idd
Feb 26 23:35:58 <stintel> maybe a NOTRACK could be added before restart and removed after
Feb 26 23:36:10 <stintel> I'll think about this some more, and maybe I can come up with something acceptable
Feb 26 23:36:47 <jow_laptop> the firewall3 should work better in this case. It uses iptables-restore to create the rules so reloads are almost atomic (flush and start are distinct operations)
Feb 26 23:37:04 <stintel> ah, that's interesting
Feb 26 23:37:04 <jow_laptop> maybe the narrower time gap is enough protection already (<5ms)
Feb 26 23:37:33 <stintel> for fast devices it might still be too long
Feb 26 23:37:59 <jow_laptop> yeah, one stray packet is enough to establish conntrack
Feb 26 23:38:32 <jow_laptop> intermediate notrack rules would be a solution
Feb 26 23:38:42 <stintel> and what I also thought about .. -i lo and -o lo is ACCEPT anyway, right? so having 127.0.0.1 in conntrack is waste of resources. or am I missing something ?
Feb 26 23:38:52 <jow_laptop> no
Feb 26 23:39:02 <jow_laptop> 127 needs to get excluded indeed
Feb 26 23:39:12 <jow_laptop> or rather the entire -i lo
Feb 26 23:39:32 <jow_laptop> erm -o l
Feb 26 23:39:37 <jow_laptop> * -o lo
Feb 26 23:39:38 <stintel> firewall3 will become default some time ?
Feb 26 23:39:48 <jow_laptop> dunno yet, it needs testing
Feb 26 23:40:10 <stintel> ok, I might switch to it on my home devices, so I can report when shit hits the fan
Feb 26 23:40:32 <jow_laptop> the old scripts happily chug along if something is broken, if the C program segfaults it will just fail completely
Feb 26 23:41:06 <stintel> right, and debugging / testing changes will become a bit harder
Feb 26 23:41:07 <jow_laptop> however it is no daemon of some sort, just a translator from uci to iptables-restore more or less
Feb 26 23:44:23 <jow_laptop> the fw3 already has a different handling of restart
Feb 26 23:44:48 <jow_laptop> its not just a dumb stop + start but it actually keeps any rules outside of the own chains
Feb 26 23:45:05 <stintel> interesting
Feb 26 23:45:13 <jow_laptop> so it should be quite easy to add the policy changing to this code path as well
Feb 26 23:46:00 <stintel> ok. one more question. not related to this. would it help if I applied for maintainership of just the x86 kvm_guest subtarget? or better just continue sending patches to the ML?
Feb 26 23:46:13 <jow_laptop> most likely it would, yes
Feb 26 23:46:22 <jow_laptop> whats missing is someone actually using it
Feb 26 23:46:32 <jow_laptop> I don't have access to any kvm system
Feb 26 23:46:34 <stintel> I'm using it, in production
Feb 26 23:46:42 <stintel> just 1 VM though
Feb 26 23:46:57 <stintel> running in datacenter, handles my openvpn connections
Feb 26 23:47:04 <russell--> lol, you don't need hardware for a vm though, right?
Feb 26 23:47:29 <stintel> well, you do. you need x86 hardware with vt-x or amd counterpart
Feb 26 23:47:34 * russell-- jokes
Feb 26 23:47:53 <jow_laptop> russell--: for me, its more about getting familiar with the entire topic (qemu, kvm, the bootloader stuff, lvm, libvirt, ....)
Feb 26 23:48:28 <stintel> yeah, that too. I'm using kvm for ~5 years now, so that helps
Feb 26 23:49:09 <russell--> just funny because usually the excuse is: oh, i can't test that because i don't have the hardware.  which doesn't really apply, but yes there's some ramping up involved
Feb 26 23:49:14 <stintel> I remember during my first serious job (read: not first line helldesk for $ISP) I went to a talk about it, it was just accepted upstream back then
Feb 26 23:49:24 <russell--> also, just "time
Feb 26 23:49:25 <russell--> "
Feb 26 23:49:27 <stintel> yeah
Feb 26 23:49:58 <stintel> jow_laptop: ok, so how to apply "officialy" ?:)
Feb 26 23:52:26 <jow_laptop> stintel: the best start is probably if you'd start sending patch series against the target
Feb 26 23:54:04 <stintel> ok, can start with 3.8 support
Feb 26 23:54:22 <stintel> and see if I give up or not ;)
Feb 26 23:55:18 <stintel> s/give up/get stuck/
Feb 26 23:56:16 <stintel> jow_laptop: did you ever notice these: 2012-06-16T23:46:12+02:00 wrt0 lldpd[21516]: asroot_gethostbyname: [priv]: unable to get system name: Operation not supported
Feb 26 23:56:45 <jow_laptop> seen a report about this in the forum
Feb 26 23:56:59 <stintel> it's a weird one. I had those on my rspro router, but not on my 2nd rspro AP
Feb 26 23:57:14 <jow_laptop> I suspect some uclibc / dns thing
Feb 26 23:57:15 <stintel> the patch I send to update to 0.7.1 seems to fix it on the router
Feb 26 23:57:16 <jow_laptop> maybe ipv6 related
Feb 26 23:57:44 <stintel> worth a bug report? or just wait for the patch to be reviewed
Feb 26 23:57:53 <jow_laptop> the 7.1 update?
Feb 26 23:57:57 <stintel> yeah
Feb 26 23:57:59 <jow_laptop> I can look into it tomorrow
Feb 26 23:58:11 <jow_laptop> if it still occurs after the update we can start looking into it
Feb 26 23:58:20 <stintel> ok, sounds good
Feb 26 23:59:15 <stintel> and I should really add ipset support on my todo list. the whole shebang, luci support etc
Feb 27 00:06:24 <jow_laptop> some ipset support is in firewall3 now
Feb 27 00:07:31 <stintel> ok, definitely need to check it out
Feb 27 00:17:01 <russell--> hmm, bridge-tools build problem: /home/russell/src/openwrt/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.6.4/../../../../mips-openwrt-linux-uclibc/sys-include/linux/if_bridge.h:172:20: error: field 'ip6' has incomplete type
Feb 27 00:17:06 <russell--> make[4]: *** [libbridge_devif.o] Error 1
Feb 27 00:18:09 <russell--> r35819 on ar71xx (with kernel v3.8)
Feb 27 00:18:47 <russell--> pushd /home/russell/src/openwrt/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.6.4/../../../../mips-openwrt-linux-uclibc/sys-include/linux/
Feb 27 00:18:53 <russell--> oops
Feb 27 00:18:55 <russell--> sry
Feb 27 02:17:05 * russell-- has a patch for bridge-tools
Feb 27 02:20:47 <stintel> interesting read about random number generation (in Linux): https://lwn.net/Articles/525459/
Feb 27 02:20:58 <stintel> rng-utils in openwrt is doing it wrong, according to this
Feb 27 02:39:34 <russell--> http://patchwork.openwrt.org/patch/3392/
**** ENDING LOGGING AT Wed Feb 27 02:59:58 2013