**** BEGIN LOGGING AT Tue Aug 18 02:59:58 2015
Aug 18 04:52:34 <plntyk> tracked down the EXTERNAL_KERNEL_TREE issue to the switching to musl ... (#20347) totally strange that external tree does NOT compile busybox while the internal one does :S
Aug 18 04:53:42 <plntyk> and I only wanted to check how "easy" it is to do kernel bisection on OpenWrt (OpenWrt running on VM/qemu)
Aug 18 07:08:48 <builder> build #78 of imx6 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/78
Aug 18 08:38:28 <OpenWrt-Commits> cyrus r46683 trunk/package/libs/polarssl/Makefile * polarssl: Fix build failures due to PKG_NAME != dir name
Aug 18 09:19:29 <OpenWrt-Commits> cyrus r46684 trunk/toolchain/musl/patches/002-fix-getsubopt.patch * musl: fix getsubopt function
Aug 18 09:21:23 <OpenWrt-Commits> cyrus r46685 trunk/config/Config-build.in * enable strong SSP / Stackprotector on gcc5
Aug 18 10:51:02 <plntyk> somebody an idea why musl fails to build with kernel ext tree ?
Aug 18 10:51:11 <plntyk> or where this might happen
Aug 18 11:10:43 <jow_laptop> plntyk: musl requires patched kernel headers afaik
Aug 18 11:12:54 <plntyk> well I did apply the generic patches in linux/generic/3.18 - let me check if I find something obvious
Aug 18 11:22:11 <OpenWrt-Commits> kaloz r46686 branches/chaos_calmer/package/kernel/mwlwifi/Makefile * mwlwifi: upgrade to 10.3.0.8-20150818
Aug 18 11:23:37 <OpenWrt-Commits> kaloz r46687 trunk/package/kernel/mwlwifi/Makefile * mwlwifi: upgrade to 10.3.0.8-20150818
Aug 18 11:24:21 <plntyk> jow_laptop: thx for the hint - i found 095-api-fix-compatibility-of-linux-in.h-with-netinet-in..patch was not applied - probably because the "..patch" was freaking out the shell or so - will try building now
Aug 18 11:28:22 <KanjiMonster> plntyk: you also need to rebuild kernel-headers so they are actually available to the toolchain
Aug 18 11:28:47 <KanjiMonster> plntyk: or switch to uclibc or (e)glibc for ext kernel tree builds ;)
Aug 18 11:30:29 <_trine> can someone tell me if the openvpn bug I found a few days ago is an openwrt bug to resolve or an up stream one
Aug 18 11:33:51 <_trine> isn't there anyone interested,, this is a bad bug because openvpn appears to complete OK but it does not open the vpn and all the communications then go out as normal
Aug 18 11:35:04 <_trine> if you were not vigilant you would be left without protection
Aug 18 11:37:56 <plntyk> asking the openvpn people might be better - there might be one who should know the correct behaviour of the various options...
Aug 18 11:39:01 <_trine> plntyk, well you could be right but this is a bug and not correct behaviour
Aug 18 11:39:17 <_trine> I have confirmed it is a bug
Aug 18 11:40:02 <_trine> by flashing an older openwrt with the same configs and the older version works as expected
Aug 18 11:40:13 <jow_laptop> what bug?
Aug 18 11:40:18 <jow_laptop> did not see a report about it
Aug 18 11:40:40 <_trine> jow_laptop, I mentioned it here a couple of days ago
Aug 18 11:40:48 <_trine> I will explain
Aug 18 11:42:31 <_trine> if I am connected to my nano to a distant AP I can connect to the VPN running on my Dockstar ok providing I connect from the netbook which is connected to the nano
Aug 18 11:42:46 <_trine> all that works
Aug 18 11:42:55 <_trine> however
Aug 18 11:43:08 <builder> build #78 of cobalt is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/78
Aug 18 11:43:57 <_trine> if i try to connect to the VPN on my Dockstar direct from the nano and watch logread -f on the nano as it is connecting
Aug 18 11:45:41 <_trine> I see it says the VPN connection has completed ok but if you look more carefully there is a message before it says the connection has been completed that the openvpn cannot find the default route
Aug 18 11:46:17 <builder> build #78 of cns21xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/78
Aug 18 11:46:30 <_trine> on the face of it it looks like the VPN has become established but it has not opened the VPN and the traffic still goes as normal
Aug 18 11:47:01 <_trine> if I revert to an earlier openwrt it all works ok
Aug 18 11:47:11 <_trine> with the same configs
Aug 18 11:47:39 <_trine> thats my best shot at trying to explain what is happening
Aug 18 11:48:33 <_trine> sorry about some of the grammar in there  :(
Aug 18 11:49:07 <builder> build #78 of orion is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/78
Aug 18 11:49:16 <_trine> is that understandable ?
Aug 18 11:54:12 <jow_laptop> not really
Aug 18 11:54:33 <jow_laptop> can you provide a log, sample configuration, last known working version etc.?
Aug 18 11:54:55 <_trine> I will try
Aug 18 12:00:07 <KanjiMonster> _trine: also maybe create a ticket for it, makes it easier to igno^Wkeep track of the status
Aug 18 12:01:44 <_trine> http://paste.debian.net/297361/
Aug 18 12:01:56 <_trine> can you see it appears to be ok
Aug 18 12:02:25 <_trine> NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Aug 18 12:02:33 <_trine> that is the difference
Aug 18 12:03:12 <_trine> in earlier versions of openwrt I dont see that and it opens the vpn ok
Aug 18 12:03:36 <_trine> but in this case all the traffic continues to use the original route
Aug 18 12:05:13 <_trine> KanjiMonster, I am not sure how to do that and I'm not confident I could explain this sufficiently well enough
Aug 18 12:06:10 <jow_laptop> and wahts the output of route -n before running openvpn?
Aug 18 12:08:52 <_trine> http://paste.debian.net/297364/
Aug 18 12:12:26 <_trine> jow_laptop, do you need any more info I need to go and have a shower
Aug 18 12:15:20 <KanjiMonster> _trine: if you can say "it works in revision foo and does not in revision bar and these are the symptoms" and provide logs then your ticket is already better than 90% of all new tickets ;)
Aug 18 12:23:33 <_trine> KanjiMonster, ok I will try, but right now I have just had a shower and need to go to a meeting
Aug 18 12:24:20 <KanjiMonster> _trine: sure thing, no need to do it now
Aug 18 12:39:10 <karlp> KanjiMonster: nice igno^w joke ;)
Aug 18 12:52:42 <jow_laptop> KanjiMonster: there's been a similar report recently here that "route" does not display the default route naymore
Aug 18 12:52:49 <jow_laptop> KanjiMonster: maybe some kernel update broke it
Aug 18 12:53:04 <jow_laptop> or did we revert back to ipv4 policy source routing? cyrusff ?
Aug 18 12:53:47 <cyrusff> nah
Aug 18 12:53:52 <cyrusff> at least i didn't
Aug 18 12:54:42 <jow_laptop> don't have a current trunk at hand to check myself atm
Aug 18 12:55:29 <SwedeMike> jow_laptop: I guess from your comment that "ip" shows it correctly, but "route" and "netstat -rn" does not?
Aug 18 12:55:50 <jow_laptop> SwedeMike: thats what I've gathered from the previous chatter here
Aug 18 12:57:07 <cyrusff> i removed all the routing table stuff from netifd after v6 subtrees worked correctly
Aug 18 12:57:28 <cyrusff> so the only reason something appears in another routing table is if you tell netifd to put the routes in a different table
Aug 18 13:00:44 <jow_laptop> ok
Aug 18 13:46:51 <karlp> jow_laptop: looking at the eof for filehandlers again,  https://pastee.org/s95mg shows it correctly getting all the chunks, just never the eof.  Same thing for a multipart/form upload works ok: https://pastee.org/78bnh
Aug 18 13:48:01 <karlp> I'm returning true from my handler, and returning that from the sink wrapper, but eof is alwaysnil,
Aug 18 13:48:45 <karlp> or am I meant to be looking at chunk coming in as nil and converting that to an eof in the sink wrapper maybe?
Aug 18 13:52:00 <karlp> http://paste.fedoraproject.org/256277/05885143/ seems to work now, just wasn't very obvious.
Aug 18 13:53:10 <karlp> what is that "err" parameter for, it's not used in either the .content() handler, nor can I see a way to use it?
Aug 18 13:56:40 <karlp> the sink function used in mimedecode_message_body doesn't have the err parameter at all?
Aug 18 14:03:19 <karlp> here's a "final" fix for it, though I can push it to github too if you'd prefer: http://paste.fedoraproject.org/256284/43990655/
Aug 18 14:06:44 <karlp> would it make sense to include the posted msg.env.CONTENT_TYPE in the "meta" parameter maybe?
Aug 18 14:31:30 <plntyk> jow_laptop: wdr3600 with 4.1.5 indeed has the route/netstat problem http://paste.debian.net/297415/
Aug 18 14:37:05 <cyrusff> plntyk: can you paste /proc/net/route as well?
Aug 18 14:37:51 <plntyk> cyrusff: http://paste.debian.net/297417/
Aug 18 14:39:02 <cyrusff> thanks
Aug 18 14:39:15 <plntyk> happy to help bug squashing :)
Aug 18 14:39:43 <cyrusff> so the route is there and also in /proc
Aug 18 14:39:50 <cyrusff> wonder whats the problem then
Aug 18 14:40:26 <zorun> does /proc/net use netlink or the old API?
Aug 18 14:40:45 <cyrusff> ummn its procfs
Aug 18 14:40:55 <cyrusff> it is a kernel generated filesystem
Aug 18 14:41:01 <zorun> hmm, ok
Aug 18 14:41:18 <cyrusff> iirc route should use that to gather its data
Aug 18 14:42:44 <zorun> I thought route used ioctl
Aug 18 14:44:31 <zorun> looks like there are 3 ways to query routes foomr the kernel?  an ioctl, netlink, and procfs
Aug 18 14:44:34 <cyrusff> not for displaying
Aug 18 14:44:53 <zorun> ah, right
Aug 18 14:45:02 <cyrusff> busybox route uses /proc/net/route(6)
Aug 18 14:45:06 <cyrusff> for showing routes
Aug 18 14:45:11 <zorun> ok
Aug 18 14:45:12 <cyrusff> and i guess netkit does the same
Aug 18 14:58:15 <jow_laptop> cyrusff: since it affects ifconfig, netstat and apparently openvpn I'd tend to assume a musl bug in *scanf()
Aug 18 15:02:05 <cyrusff> yeah probably
Aug 18 15:03:34 <cyrusff> or some obscure gnu extension everybody uses
Aug 18 15:06:12 <jow_laptop> I suspect a bug in https://github.com/bpowers/musl/blob/master/src/internal/intscan.c#L26
Aug 18 15:06:28 <jow_laptop> when dealing with hex literals containing only '0'
Aug 18 15:06:48 <jow_laptop> juyt a hunch though
Aug 18 15:08:06 <cyrusff> i have this in odhcpd though and it seems to work: https://github.com/sbyx/odhcpd/blob/master/src/router.c#L174
Aug 18 15:09:17 <jow_laptop> the difference is that busybox checks for sscanf(...) == 11
Aug 18 15:09:27 <jow_laptop> your code just for != 0
Aug 18 15:10:55 <jow_laptop> openvpn also checks the count returned by *scanf()
Aug 18 15:11:23 <jow_laptop> so my working theory is that all zero hex literals are maybe matched but not counted or sth.
Aug 18 15:11:50 <cyrusff> i guess somebody has to powerup a gdb
Aug 18 15:18:29 <builder> build #74 of uml is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/74
Aug 18 15:20:24 <jow_laptop> my wrong literal parsing idea is wrong I think, busybox ifconfig aborts on the first line with != 11 fields, so it wouldn't display the rest
Aug 18 15:20:48 <jow_laptop> the only nonfatal case which would cause it to skip one line is if (routeflags & RTF_UP) === 0
Aug 18 15:22:11 <jow_laptop> it is unlikely that RTF_UP is defined as something != 0x0001
Aug 18 15:22:34 <cyrusff> plus in the pastes there are other rotues with flags 0003 and they are printed
Aug 18 15:25:33 <jow_laptop> maybe this initial header skip expression is overmatching: fscanf(fp, "%*[^\n]\n")
Aug 18 15:25:36 <builder> build #74 of avr32 is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/74
Aug 18 15:36:57 <builder> build #72 of octeon is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/72
Aug 18 15:40:22 <jow_laptop> karlp: can you rework your filecb patch to create a local { name = "raw" } outside of the closure to avoid creating a table with every chunk?
Aug 18 15:40:27 <cyrusff>  i'm compiling a new toolchain for vbox anyway
Aug 18 15:40:36 <cyrusff> so maybe i will find some time later to have a look
Aug 18 15:40:44 <jow_laptop> I was unable to reproduce the problem with x86/generic on qemu
Aug 18 15:40:57 <cyrusff> something funny with be maybe
Aug 18 15:40:58 <jow_laptop> seems to arch specific
Aug 18 15:41:09 <jow_laptop> any recent gcc update?
Aug 18 15:42:37 <cyrusff> hmm not that i know of
Aug 18 15:42:45 <cyrusff> i want to test gcc 5.2
Aug 18 15:42:52 <cyrusff> and finish the hardening stuff there
Aug 18 15:45:06 <karlp> jow_laptop: sure, totally, hwo about this: http://paste.fedoraproject.org/256331/39912684/
Aug 18 15:49:52 <plntyk> cyrusff: there is some compile error regarding c++ and uclibc++ which naturally breaks a lot of packages - something with templates and such :S dont know any c++ and didnt see a patch in uclibc++ repo (its not updated since 2013 anyway)
Aug 18 15:50:47 <cyrusff> sorry i don't feel masochistic enough for c++ today ;)
Aug 18 15:50:54 <plntyk> and https://github.com/wongsyrone/openwrt-1/issues/44 says that gcc5 is still broken on arm but I dont have any arm board ...dunno where this was tested
Aug 18 15:52:44 <jow_laptop> karlp: pushed to both master & for-15.05
Aug 18 15:53:25 <karlp> excellent, thanks.  I didn't need that content type bit, it just seemed like worthwhile for the "unhandled content type" path.
Aug 18 15:53:42 <karlp> now I just need to update my own tree to 15.05 :)
Aug 18 15:54:36 <jow_laptop> cyrusff: unable to reproduce on the realview qemu snapshot as well
Aug 18 15:54:51 <cyrusff> is that big endian?
Aug 18 15:54:52 <jow_laptop> cyrusff: (which is litle endian too afair) so probably big endian
Aug 18 15:54:57 <cyrusff> ah okay
Aug 18 15:55:07 <jow_laptop> *so probably a big endian specific problem
Aug 18 15:55:37 <cyrusff> let me check my wndr3800 i had with me in prague
Aug 18 15:55:45 <cyrusff> i think these should ahve gdb
Aug 18 15:55:52 <cyrusff> though probably no debug symbols ...
Aug 18 15:55:56 <cyrusff> for busybox
Aug 18 15:57:47 <jow_laptop> an osilated test program would be enough already
Aug 18 15:57:50 <jow_laptop> *isolated
Aug 18 15:58:11 <jow_laptop> http://pastebin.com/03SXQjsJ
Aug 18 16:01:33 <cyrusff> *sigh* might as well grab the router
Aug 18 16:01:41 <cyrusff> it has been constantly raining since i woke up at 7 today
Aug 18 16:01:49 <cyrusff> still is
Aug 18 16:07:00 <jow_laptop> here as well :)
Aug 18 16:07:33 <karlp> here too :)
Aug 18 16:07:50 <karlp> just drizzle though here at least.
Aug 18 16:08:04 <jow_laptop> heavy rain since yesterday, will continue until tomorrow
Aug 18 16:08:55 <jow_laptop> apart from the lack of light its quite refreshing though, after weeks with temperatures > 30°
Aug 18 16:09:03 <jow_laptop> and without rain :)
Aug 18 16:10:44 <karlp> yeah, it was a hot summer in continental europe I hear?
Aug 18 16:11:05 <jow_laptop> quite
Aug 18 16:11:15 <mamarley> Do you guys have air conditioning?
Aug 18 16:11:23 <jow_laptop> here? not really
Aug 18 16:11:31 <jow_laptop> quite rare in eastern germany
Aug 18 16:11:33 <mamarley> Ooh, that sucks.  Sorry. :(
Aug 18 16:14:05 <KanjiMonster> air conditioning usually isn't worth it for the few days we usually get; this summer was exceptionally hot
Aug 18 16:15:18 <mamarley> Where I live (southeast US), it commonly gets in the 30degC range, along with >75% RH.  Air conditioning is not an option; it is required.
Aug 18 16:15:40 <cyrusff> i was vacationing in greece last week, was glad to have A/C ;)
Aug 18 16:15:55 <cyrusff> but yeah no A/C here at home, usually not worth it
Aug 18 16:16:37 <cyrusff> but falt in good old brick building from 190X so it doesn't get that hot if you keep windows shut ;)
Aug 18 16:19:31 <cyrusff> jow_laptop: https://gist.github.com/anonymous/7b5cb26af4a280805240
Aug 18 16:19:42 <cyrusff> musl 1.1.10
Aug 18 16:19:50 <cyrusff> but kernel 3.18.18 on ar71xx
Aug 18 16:23:31 <jow_laptop> looks okay
Aug 18 16:23:47 <cyrusff> yep so musl and be seem to work (with older kernels)
Aug 18 16:23:57 <cyrusff> wasn't so easy ;)
Aug 18 16:25:15 <jow_laptop> you could flash a snapshot
Aug 18 16:25:37 <cyrusff> you are talking me into this, aren't you? :P
Aug 18 16:25:49 <jow_laptop> yes :)
Aug 18 16:26:08 <jow_laptop> there's 1.5km of rain between here and the next ar71xx device :P
Aug 18 16:26:45 <cyrusff> haha
Aug 18 16:36:17 <cyrusff> jow_laptop: confirmed with 4.1
Aug 18 16:38:11 <jow_laptop> hm
Aug 18 17:21:58 <builder> build #75 of mxs is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/75
Aug 18 17:23:03 <cyrusff> jow_laptop: looks like your suspicion was correct
Aug 18 17:23:16 <cyrusff> after the initial fscanf(fp, "%*[^\n]\n")
Aug 18 17:23:27 <cyrusff> the subsequent fscanf matches the 3rd line
Aug 18 17:23:34 <cyrusff> instead of the 2nd with the default route
Aug 18 17:23:50 <netprince> plntyk: I cant seem to find it... do I need to uncomment one of the feeds?  which one?
Aug 18 17:25:35 <plntyk> its in the packages feed on github https://github.com/openwrt/packages its description  is right there on that page
Aug 18 17:26:17 <netprince> yes, I see that, so why doesn't it show up in make menuconfig?
Aug 18 17:26:29 <_trine> jow_laptop, were you able to reach any conclusions re the openvpn problem?
Aug 18 17:27:04 <netprince> _trine: remind me of your openwrt problem?  I've been working with it a little lately...
Aug 18 17:27:43 <cyrusff> _trine: some fuckup with newer kernels and possibly musl
Aug 18 17:28:05 <cyrusff> route and openvpn parse /proc/net/route incorrectly
Aug 18 17:28:38 <cyrusff> 3.18.18 with musl works, 4.1 does not
Aug 18 17:28:45 <jow_laptop> same musl version?
Aug 18 17:28:55 <_trine> netprince, well when I run openvpn from inside my device it seems to complete the VPN connection but in actuality all the packets still go out in the same way as they did before initiating the vpn
Aug 18 17:29:02 <_trine> thanks cyrusff
Aug 18 17:29:17 <cyrusff> think so
Aug 18 17:29:25 <cyrusff> build the other image 3 or 4 weeks ago
Aug 18 17:30:24 <_trine> cyrusff, at least now i know I'm not quite as mad as I thought I was :)
Aug 18 17:32:25 <_trine> net this is what you see as the VPN is initiating NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Aug 18 17:32:31 <_trine> netprince,
Aug 18 17:33:00 <_trine> but after that the VPN appears to complete OK with Initialization Sequence Completed
Aug 18 17:33:16 <netprince> _trine: I haven't been trying to redirect the default gateway, just redirect some routes, perhaps I have avoided that issue
Aug 18 17:33:20 <_trine> which makes you think the VPN is up and it isn't
Aug 18 17:33:56 <netprince> _trine: I haven't been trying trunk, been on cc
Aug 18 17:34:02 <_trine> ok
Aug 18 17:34:34 <_trine> cyrusff, has given the answer anyway so i know its in good hands now
Aug 18 17:34:47 <_trine> my job is done
Aug 18 17:38:21 <plntyk> netprince: you probably forgot to ./scripts/feeds install -a so that the package gets listed in menuconfig
Aug 18 17:38:35 <netprince> plntyk: I see other packages in the github feed, apache, bind, bmon
Aug 18 17:39:51 <plntyk> it should show on search too ("/" key)
Aug 18 17:40:16 <netprince> plntyk: yup, thats what its not doing
Aug 18 17:40:29 <netprince> very strange, it works for you?
Aug 18 17:41:27 <plntyk> yes - it you should see the dirs in feeds/packages(/net/pptpd)  too
Aug 18 17:41:37 <netprince> the folder is not in chaos_calmer/feeds/packages/net
Aug 18 17:41:54 <netprince> all the other folders are
Aug 18 17:42:01 <cyrusff> jow_laptop: sorry seems the older router might have had uclibc and not musl
Aug 18 17:42:02 <plntyk> ah wait
Aug 18 17:42:06 <cyrusff> hmm
Aug 18 17:42:08 <cyrusff> wtf
Aug 18 17:42:11 <cyrusff> i could have sworn
Aug 18 17:42:15 <cyrusff> anyway
Aug 18 17:42:45 <plntyk> netprince: pptpd is not in 14.07 branch or in 15.05 because probably at that time it was not yet in github
Aug 18 17:43:06 <cyrusff> pptp is evil anyway
Aug 18 17:43:08 <plntyk> yes
Aug 18 17:43:18 <plntyk> should be removed for security reasons ^^
Aug 18 17:44:02 <plntyk> like someone asked why his hostapd or so what not authing because the university was using weak keys (<768bits) that were blocked by hostapd
Aug 18 17:44:42 <netprince> plntyk: so basically back to my original question, was it deleted on purpose, or is something wrong?
Aug 18 17:45:24 <cyrusff> https://forum.openwrt.org/viewtopic.php?id=52219
Aug 18 17:45:28 <cyrusff> netprince: ^
Aug 18 17:45:32 <plntyk> netprince: nothing wrong - if you use 14.07 or 15.05 then pptpd is not available unless you enable the "oldpackages" repo
Aug 18 17:46:09 <netprince> its not in oldpackages, I already enable that by default
Aug 18 17:46:24 <cyrusff> it was removed from there
Aug 18 17:46:30 <cyrusff> when it was merged
Aug 18 17:46:44 <plntyk> roll back the oldpackages repo to the date when it was deleted and use that locally
Aug 18 17:46:47 <cyrusff> but that was after 15.05
Aug 18 17:47:08 <plntyk> or c/p the whole dir into your packages/ dir
Aug 18 17:47:44 <netprince> that was the plan, if it was deleted on purpose
Aug 18 18:03:17 <zorun> cyrusff: the only kernel commit I found who could change the output format is 652586df95e5d76b37d07a11839126dcfede1621, but it's from 2013
Aug 18 18:03:39 <zorun> the function is fib_route_seq_show in net/ipv4/fib_trie.c
Aug 18 18:04:42 <cyrusff> yeah its probably musl related
Aug 18 18:04:49 <cyrusff> i think i confused my routers
Aug 18 18:04:51 <cyrusff> i have too many
Aug 18 18:04:53 <zorun> :)
Aug 18 18:05:48 <cyrusff> i just confirmed the headers are identical between kernel versions
Aug 18 18:37:11 <jow_laptop> cyrusff: there was a recent musl update
Aug 18 18:37:30 <jow_laptop> cyrusff: which introduced some locale / wchar related changes
Aug 18 18:37:53 <jow_laptop> since *scanf() uses mbrtowc() internally it might have side effects
Aug 18 18:38:28 <jow_laptop> the scanf code is hard to understand so I need to step through it at some point
Aug 18 18:39:04 <jow_laptop> so far I simply can not see where/how it handles escape sequences within character classes
Aug 18 18:55:15 <cyrusff> jow_laptop: there is no escape sequence
Aug 18 18:55:24 <cyrusff> \n is translated by the c-compiler
Aug 18 19:43:46 <plntyk> hm... gdb on router and busybox with debug fits even with luci in router  - anybody wanting some command/output?
Aug 19 02:46:48 <builder> build #74 of ar71xx.mikrotik is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/74
**** ENDING LOGGING AT Wed Aug 19 02:59:58 2015