**** BEGIN LOGGING AT Mon Jan 06 02:59:57 2020
Jan 06 05:04:25 <owrt-1907-builds> build #96 of armvirt/32 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/96  blamelist: Klaus Kudielka <klaus.kudielka@gmail.com>, Maxim Storchak <m.storchak@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Jack Chen <redchenjs@live.com>, Jo-Philipp Wich <jo@mein.io>,
Jan 06 05:04:25 <owrt-1907-builds> Hauke Mehrtens <hauke@hauke-m.de>
Jan 06 05:27:57 <owrt-1907-builds> build #97 of mvebu/cortexa72 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/97
Jan 06 06:59:12 <owrt-1806-builds> build #55 of mpc85xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mpc85xx%2Fgeneric/builds/55
Jan 06 07:17:06 <jow> anyone here experienced with hosting git over http / gitweb?
Jan 06 07:17:36 <jow> I wonder about our frequent git.openwrt.org gateway timeouts, despite the generally low server load (0.2~0.4)
Jan 06 07:18:24 <jow> given that its a virtual DO instance it is probably crappy IO contributing to the problem but I would've expected the fscache to mitigate that eventually
Jan 06 07:32:44 <owrt-snap-builds> build #208 of imx6/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/imx6%2Fgeneric/builds/208
Jan 06 07:32:47 <owrt-1806-builds> build #55 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ipq40xx%2Fgeneric/builds/55
Jan 06 07:34:53 <owrt-snap-builds> build #207 of gemini/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/gemini%2Fgeneric/builds/207
Jan 06 07:48:39 <owrt-1806-builds> build #55 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ramips%2Frt3883/builds/55
Jan 06 08:09:34 <PaulFertser> Hauke: btw, since you saw dnsmasq segfaulting but procd didn't notice anything, that's a strong hint that a TCP request was involved.
Jan 06 08:25:52 <owrt-1806-builds> build #55 of apm821xx/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/apm821xx%2Fnand/builds/55
Jan 06 08:45:03 <owrt-snap-builds> build #197 of brcm2708/bcm2710 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/brcm2708%2Fbcm2710/builds/197  blamelist: Tokunori Ikegami <ikegami.t@gmail.com>, Rosen Penev <rosenp@gmail.com>, Bj?rn Mork <bjorn@mork.no>, Petr ?tetiar <ynezz@true.cz>, Christian Lamparter <chunkeey@gmail.com>, Andrea
Jan 06 08:45:04 <owrt-snap-builds> Dalla Costa <andrea@dallacosta.me>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Christoph Krapp <achterin@googlemail.com>, Matt Merhar <mattmerhar@protonmail.com>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Jack Chen <redchenjs@live.com>, Yong-hyu Ban <perillamint@quendi.moe>, Andreas B?hler <dev@aboehler.at>, Josef Schlehofer
Jan 06 08:45:04 <owrt-snap-builds> <pepe.schlehofer@gmail.com>, Jo-Philipp Wich <jo@mein.io>, Hauke Mehrtens <hauke@hauke-m.de>, Mason Clarke <mclarke2355@gmail.com>
Jan 06 08:46:01 <owrt-1806-builds> build #57 of mvebu/cortexa72 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mvebu%2Fcortexa72/builds/57  blamelist: Jack Chen <redchenjs@live.com>, Hauke Mehrtens <hauke@hauke-m.de>, Florian Fainelli <f.fainelli@gmail.com>
Jan 06 08:46:01 <owrt-snap-builds> build #183 of layerscape/armv7 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/183  blamelist: Tokunori Ikegami <ikegami.t@gmail.com>, Rosen Penev <rosenp@gmail.com>, Bj?rn Mork <bjorn@mork.no>, Petr ?tetiar <ynezz@true.cz>, Christian Lamparter <chunkeey@gmail.com>, Andrea
Jan 06 08:46:01 <owrt-snap-builds> Dalla Costa <andrea@dallacosta.me>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Christoph Krapp <achterin@googlemail.com>, Matt Merhar <mattmerhar@protonmail.com>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Jack Chen <redchenjs@live.com>, Yong-hyu Ban <perillamint@quendi.moe>, Andreas B?hler <dev@aboehler.at>, Josef Schlehofer
Jan 06 08:46:01 <owrt-snap-builds> <pepe.schlehofer@gmail.com>, Jo-Philipp Wich <jo@mein.io>, Hauke Mehrtens <hauke@hauke-m.de>, Mason Clarke <mclarke2355@gmail.com>
Jan 06 09:08:22 <xback> G'Morning all
Jan 06 09:08:45 <xback> Hauke: Thanks for doing the kernel bumps during my holidays
Jan 06 10:14:20 <blogic>  /msg ynezz hi
Jan 06 10:14:24 <blogic> grrr
Jan 06 11:45:28 <owrt-1907-builds> build #98 of mvebu/cortexa72 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/98  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 12:45:26 <owrt-1907-builds> build #97 of armvirt/32 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/97
Jan 06 14:20:33 <Hauke> xback: I wanted to have a recent kernel in the release
Jan 06 14:22:06 <Hauke> PaulFertser: wheer do you see that procd did not notice the crash?
Jan 06 14:22:54 <PaulFertser> Hauke: I thought you checked the logread and saw only that segfault message, and no other evidence, so I guessed it was dnsmasq's child, not dnsmasq itself.
Jan 06 14:24:01 <PaulFertser> Hauke: in any case, that commit message fixing crash you linked to is touching the code that's not exercised with regular udp requests. dnsmasq forks for handling tcp requests and then it uses pipes to communicate with the main instance.
Jan 06 14:45:22 <owrt-1907-builds> build #83 of ath79/nand is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fnand/builds/83  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 14:45:29 <owrt-1907-builds> build #78 of x86/legacy is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/78  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 14:45:37 <owrt-1907-builds> build #78 of mxs/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mxs%2Fgeneric/builds/78  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 14:46:14 <owrt-1907-builds> build #88 of ar71xx/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fgeneric/builds/88  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 14:46:34 <owrt-1907-builds> build #79 of lantiq/xrx200 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/79  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 14:47:12 <owrt-1907-builds> build #78 of imx6/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/imx6%2Fgeneric/builds/78  blamelist: Petr ?tetiar <ynezz@true.cz>
Jan 06 14:55:55 <Hauke> PaulFertser: I used dmesg, the logread only stores it for about 2 days
Jan 06 14:56:01 <Hauke> and this happended 18 days ago
Jan 06 14:56:42 <Hauke> when I do "dig SRV jabber.org +tcp" I get an TCP error without the patch
Jan 06 14:56:51 <Hauke> with the patch it behaves like the UDP request
Jan 06 15:06:59 <PaulFertser> Hauke: hm, weird, for me with TCP I get regular "first time" reply each time, and with UDP just the first time. And then with TCP I'm getting it from the cache.
Jan 06 15:08:35 <Hauke> PaulFertser: I had this: https://pastebin.com/6me5CDX7
Jan 06 15:08:43 <Hauke> but now it work
Jan 06 15:10:27 <PaulFertser> Hauke: surely no new segfaults in dmesg during the first tries?
Jan 06 15:12:00 <PaulFertser> Hauke: I'd expect those tcp children to probably crash during the addition to the cache, yes. And then the TCP socket would close unexpectedely.
Jan 06 15:15:15 <Hauke> no I havne't seen any crashes
Jan 06 15:16:14 <PaulFertser> Weird. But it doesn't answer a legit query so that's bad enough already, I'd say worth cherry-picking that fix.
Jan 06 15:17:14 <Hauke> as far as I understood this the answer we get is just an additional information and this is probably not chached
Jan 06 15:18:08 <Hauke> when I request a real SRV record like this: "dig SRV _udp.sipgate.de +tcp" it behaves differently
Jan 06 15:18:19 <Hauke> but it always queries the master server
Jan 06 15:19:02 <Hauke> no sorry, I meant this: "dig SRV _stun._udp.sipgate.de +tcp" it works like expected
Jan 06 15:21:19 <PaulFertser> The answer was cached on first request. With UDP it's cached right away and with TCP it's passed from the children to master process. This is the part that failed. Probably crashing children in certain cases.
Jan 06 15:34:17 <karlp> jow: I was going to go and update a luci app that doesn't have any translation tags (yet) but do I need to convert it to a .js modle first?  what sort of timeline do you have in mind for moving all the existing apps over to nto use luci-compat?
Jan 06 16:06:41 <Hauke> jow: How can we hanle all these "fatal: unable to access 'https://git.openwrt.org/openwrt/openwrt.git/': The requested URL returned error: 504" problems in the build when we trigger the release builds?
Jan 06 16:52:45 <Hauke> PaulFertser: I committed the fix now, it could be that it only crashes when something else is comming afterwards in the pipe
Jan 06 16:52:47 <Hauke> I am not sure
Jan 06 16:53:13 <Hauke> in general is there anything missing in the 19.07 or 18.06 branch, I would like to tag it in some hours
Jan 06 16:57:31 <zorun> \o/
Jan 06 16:57:39 <zorun> Hauke: maybe send a last reminder by email?
Jan 06 16:59:53 <stintel> Hauke: any objections against cherry-pick db26f53bb353b8ddf3ad1ef3057eb59648a077e8 and 157e17e985ea494f7f0a870df0afa0a837eccb8c  to 19.07 ?
Jan 06 17:05:35 <Hauke> stintel: looks ok to me
Jan 06 17:06:01 <stintel> I should have done it earlier, my bad
Jan 06 17:06:54 <stintel> > warning: inexact rename detection was skipped due to too many files.
Jan 06 17:07:06 <stintel> nvm then
Jan 06 17:07:24 <karlp> iirc you can tweak that limit, it's too low for kernel by default or something
Jan 06 17:08:02 <stintel> well I'm at day job, no time for it right now really, so sol
Jan 06 17:16:01 <stintel> apparently it's the smallbuffers backport that causes trouble now
Jan 06 17:24:27 <Hauke> stintel: which?
Jan 06 17:27:27 <stintel> ath10k-ct smallbuffers for 64MB devices
Jan 06 17:28:00 <stintel> it's probably going to cause issues for most of the new device support that hadn't been cherry-picked to 19.07 before
Jan 06 17:28:16 <stintel> let's keep it for .1 then
Jan 06 17:28:22 <Hauke> ok
Jan 06 19:13:14 <owrt-snap-builds> build #228 of x86/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/228
Jan 06 19:25:20 <ynezz> Hauke: ship it! :)
Jan 06 21:02:41 <stintel> https://www.ofmodemsandmen.com/
Jan 06 21:02:54 <stintel> ¯\_(ツ)_/¯
Jan 06 21:03:36 <ldir> Sorry chaps, a combination of work & my macbook being away in Germany for repair means my involvement is low at the moment.  Hopefully Dieter the detail meister will have it repaired soon.
Jan 06 21:04:21 <stintel> ldir: o/
Jan 06 21:05:21 <ldir> I also wish that Simon would do a release of dnsmasq
Jan 06 21:06:06 <stintel> and I was just thinking I need to do a release of vallumd. got complaints that mixing versions doesn't work ...
Jan 06 21:06:11 <stintel> well duh :P
Jan 06 21:06:36 <stintel> and that's how I found that ofmodemsandman "fork"
Jan 06 21:06:48 <ldir> reboot? ;-)
Jan 06 21:06:55 <stintel> :P
Jan 06 21:07:10 <karlp> is it anything more than packaged binaries? is it really much of a fork?
Jan 06 21:07:19 <stintel> theire last news item is from 10.03.2019, announcing their new release based on 18.06.1
Jan 06 21:07:40 <stintel> maybe I should inform this chap his firmware has lots of security bugs?
Jan 06 21:08:55 <stintel> https://www.ofmodemsandmen.com/other.html "If you wish to build your own ROOter images you need the ROOter Build System, as ROOter is now a fork of OpenWrt. We provide it here."
Jan 06 21:09:02 <stintel> with a link to a zip in google drive
Jan 06 21:09:04 <stintel> le sigh
Jan 06 21:10:30 <stintel> that's enough internet for me for today
Jan 06 21:11:20 <ldir> correct :-)
Jan 06 21:12:10 <ldir> I'm having a slightly enforced digital detox :-/
Jan 06 21:15:22 <ldir> the mac mini I'm using at the moment has a 'large' but SLOOOOOOOOOOW spinning rust drive that really sucks the performance out of it.  Tomorrow brings (hopefully) a 1TB SSD that should have arrived today.
Jan 06 21:15:35 <Hauke> ldir: Simon said in November that he plans a new dnsmasq soon
Jan 06 21:16:03 <Hauke> dnsmasq release soon
Jan 06 21:16:24 <Hauke> would be nice so we do not have to carry all these patches
Jan 06 21:17:44 <ldir> There are over 100 commits between now and 2.80 so you saying 'all these patches' makes me laugh because I've maintained my own commit to run as new as I can to spot obvious issues.
Jan 06 21:18:30 <PaulFertser> ldir: a bit offtopic, but do you know if dslreports.com lie about their units or do they really mean megabits/s?
Jan 06 21:19:39 <ldir> I'm going to switch my local dnsmasq package commit to git and point at master
Jan 06 21:20:06 * ldir goes to look PaulFertser 
Jan 06 21:20:42 <PaulFertser> ldir: asking because when playing with SQM I got an impression they might be meaning mebibits/s , at least that matched the restriction set in config.
Jan 06 21:21:00 <PaulFertser> And their speedtest is the most recommended since they sensibly evaluate bufferbloat.
Jan 06 21:21:39 <ldir> It's certainly bits, not bytes, but whether it's mebi or mega ???  A good question for their forum if they have one
Jan 06 21:22:19 <PaulFertser> If you have iftop handy you can try measuring that yourself.
Jan 06 21:22:22 <PaulFertser> I guess
Jan 06 21:22:55 <PaulFertser> If you're not sure I'll just send an email to their speedtest contact.
Jan 06 21:23:06 <ldir> I have no idea
Jan 06 21:23:12 <PaulFertser> Yeah, ok, thank you.
Jan 06 21:24:12 <olmari> hmm... is there any particular reason luci-ssl is responding slow as ef with x86? openssl, anc made sure both random and urandom keeps giving... no matter are they self-signer cert or LE
Jan 06 21:24:34 <olmari> tried to clear caches and cookies
Jan 06 21:24:49 <olmari> http works snappy as heck if disabled rediction to https
Jan 06 21:26:01 <Hauke> olmari: mbedtls needs about 1 second on slow mips devices to create a new TLS session and chrome starts with 5
Jan 06 21:26:06 <Hauke> openssl is much faster
Jan 06 21:26:10 <Hauke> on mips
Jan 06 21:26:17 <Hauke> but we use a session cache
Jan 06 21:26:19 <Hauke> now
Jan 06 21:26:46 <olmari> Hauke: well... this is 30sec or most pages even "XHR request time out"
Jan 06 21:27:08 <olmari> x86-64 atom D330, so while not new, definately not slow on this context
Jan 06 21:27:33 <Hauke> ok that should be fast
Jan 06 21:27:41 <Hauke> compared to 500Mhz mips
Jan 06 21:27:46 <olmari> I do have some tplink wdr4300 running elsewhere with at least year old owrt, it works just fine over https
Jan 06 21:28:17 <hell__> ah, that atom is a literal dual core chip, has two dies next to each other :D
Jan 06 21:28:34 <olmari> sure, I do get the, say, 1sec type delau on first go and so on, but in grand scheme that still works normally, while this new one does not
Jan 06 21:29:32 <olmari> hell__: yeps.. plus hyperthreading... I did make sure to enable multicore and HTT on kernel_,menuconfig too, but anyways...
Jan 06 21:30:07 <olmari> I don't know how to troubleshoot anymore... "top" doesn't show any meaningful load nor logread reveal anything
Jan 06 21:35:24 <olmari> hmm... I think option rfc1918_filter '0' did the trick, maybe possibly... though I might test this further, and also do some split DNS, so address gives LAN ip to lan
Jan 06 21:36:02 <Hauke> does anyone has the password for the 18.06 buildbot?
Jan 06 21:36:10 <Hauke> I asked jow but he seams to be offline
Jan 06 21:36:53 <olmari> I don't know why would that option hinder perf when accessed through local IP.. it will ofcourse error out properly when doing public IP/domainname
Jan 06 21:36:58 <olmari> from local net
Jan 06 21:42:55 <olmari> hmm... made hosts file mark for said domain for LAN-IP... having rebind protection on uhttpd enabled, going with dnsname it agai nworks fine, when I go with LAN-IP directly it's again not working.. so I don't know what gives there, as only diffirence is not hostname vs IP, where hostname resolves to same IP
Jan 06 21:45:13 <olmari> I get literally same (propably unrelated) 404 for some whatever file on both methods, so it's not that either
Jan 06 21:53:48 <Hauke> 19.07.0 is tagged and the builds are started
Jan 06 21:54:06 <Hauke> 18.06.6 is tagged but I do not have the password to start the builds ;-)
Jan 06 21:54:07 <olmari> sweet =)
Jan 06 21:54:09 <stintel> Hauke: thanks a bunch!
Jan 06 21:54:35 <olmari> status update: chromium engine / vivaldi might also play part... FF seems to work just fine
Jan 06 21:54:40 <Hauke> I will prepare the changelog
Jan 06 21:54:50 <Hauke> the build should be finished in about 36 hours
Jan 06 21:58:26 <olmari> jow: summary from this recent "bug", FF works, chromium/vivaldi does not, culprit is httpS://IP-number, loads often forever with dynamic content, with hostname (pointing to same IP) everything suddenly works
Jan 06 21:58:46 <olmari> cert valid or self-signed does not matter
Jan 06 21:59:28 <olmari> adblockers disabled etc for test
Jan 06 22:00:48 <olmari> I mean yes at this point it could be something odd with browser itself too, but how the eff I'd find that... otherwise both FF and Vivaldi behaves exactly similar, with console content and all
Jan 06 22:02:43 <karlp> is it doing a dns reverse lookup and failing? the way ssh hangs on connecting sometimes? (UseDNS setting in sshd config?)
Jan 06 22:03:21 <olmari> karlp: everything else works so far
Jan 06 22:03:27 <dangole> happy 19.07 release everyone :)
Jan 06 22:03:46 <olmari> ssh, http with IP number access (when rediction disabled)
Jan 06 22:04:36 <olmari> what wonders me most is that only diffirence is http vs https.. if it would be purely dns resolving issue then it would happend with http alike
Jan 06 22:06:33 <olmari> dangole: thank you, you too (:
Jan 06 22:13:27 <olmari> Anyway, I'm glad I sorted this one out, or more of method to not needing to care :)
Jan 06 22:15:07 <olmari> now I have dns-over-https, with ntpd/pool.ntp.org in separate server-file to resolve always, and dyndns works, while having the actual hostname in "split-dns" or resolved to lan-ip in lan and otherwise public in public
Jan 06 22:32:22 <olmari> hrhm... I still do thing it has something to do with valid hostname/ssl-cert... as other device with invalid SSL does also not work while used with dns-name
Jan 06 22:32:53 <olmari> so mystery still isn't fully resolved
Jan 06 22:41:27 <Hauke> zorun: I created this page https://openwrt.org/releases/19.07/notes-19.07.0
Jan 06 22:41:53 <Hauke> the builds will not finish before wednesday
Jan 07 00:50:15 <owrt-1907-builds> build #99 of mvebu/cortexa72 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/99
**** ENDING LOGGING AT Tue Jan 07 02:59:58 2020