**** BEGIN LOGGING AT Tue Feb 25 02:59:57 2020
Feb 25 06:11:50 <aparcar[m]> jow: do you have a comment on the versions.json file mail thread?
Feb 25 07:49:52 <abenz> lynxis: the nodogsplash version in 19.07 seems to have memory leak (150MB+ usage after a few days).. I see in github that many newer versions were released and changlogs mention memory fixes
Feb 25 07:50:38 <abenz> will there be an update to 19.07 branch? some functionality changed, but given current version has serious flaw.. warrants a push?
Feb 25 08:43:13 <aparcar[m]> ugh all imagebuilders are currently broken...?
**** BEGIN LOGGING AT Tue Feb 25 15:26:37 2020
Feb 25 16:06:45 <blogic> stintel: can you see if my latest wifi patch fixes your issue ?
Feb 25 16:12:25 <blogic> xback: ping
Feb 25 16:12:36 <xback> blogic: pong
Feb 25 16:12:46 <blogic> xback: can you merge some of my v5.4 stuff ?
Feb 25 16:12:53 <xback> ofc
Feb 25 16:12:56 <blogic> i guess i should rebase upon your tree first
Feb 25 16:13:11 <blogic> i have a for_koen branch in my staging
Feb 25 16:13:14 <xback> yes please
Feb 25 16:13:21 <blogic> let me rebase that just now
Feb 25 16:13:26 <xback> please do
Feb 25 16:13:35 <xback> We're aiming to merge later this week
Feb 25 16:13:47 <xback> to master
Feb 25 16:14:26 <mamarley> xback: I tried your 5.4 stuff on my UAP-LR again yesterday and it compiles cleanly now, but still bootloops.  I still don't have serial on it, but it loops right away even before the normal LED-flashing it should give during bootup, so it seems to be crashing very early on.
Feb 25 16:14:59 <xback> mamarley: which target is this specifcally?
Feb 25 16:15:07 * mamarley checks…
Feb 25 16:15:58 <mamarley> xback: CONFIG_TARGET_DEVICE_ath79_generic_DEVICE_ubnt_unifi
Feb 25 16:16:15 <xback> thnx
Feb 25 16:17:03 <xback> mamarley: fyi, https://github.com/openwrt/openwrt/pull/2789
Feb 25 16:18:23 <mamarley> I guess that could be it.  I haven't tried a 4.19 master build on it recently, but I can do that later today.
Feb 25 16:21:50 <adrianschmutzler> Not sure whether it's unifi or unifiac there, but both have 25 MHz and shouldn't be affected by the flash issue
Feb 25 16:22:46 <mamarley> OK, yeah, that's what I was about to check.  I also have a UAP-AC-PRO on which I am running master builds and that works fine, so…
Feb 25 16:23:08 <adrianschmutzler> all unifiac seem to have spi 25 MHz
Feb 25 16:31:49 <adrianschmutzler> blogic: # CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
Feb 25 16:32:03 <adrianschmutzler> That should be "... is not set" instead?
Feb 25 16:32:06 <adrianschmutzler> https://github.com/openwrt/openwrt/commit/ffd249366f96a6a94fac18909109a6c98a458de7
Feb 25 16:32:24 <adrianschmutzler> Ah, sorry, it's not blogic, its ldir
Feb 25 16:32:38 <adrianschmutzler> ldir: ^
Feb 25 16:34:50 <ldir> adrianschmutzler: oh, should it ?  It seemed to work for me as it is, I guess accident than design.
Feb 25 16:35:39 <adrianschmutzler> as I understand it, it's either "OPTION=y" or "# OPTION is not set"
Feb 25 16:36:05 <ldir> oops - accident it is then!  Will fix up
Feb 25 16:36:39 <adrianschmutzler> someone else might correct me if I'm wrong, I'm rarely dealing with the configs as well
Feb 25 16:37:42 <ldir> no you're right - I don't know what I was thinking
Feb 25 16:40:47 <xback> ldir: ping
Feb 25 16:40:55 <ldir> xback: pong
Feb 25 16:41:13 <xback> nm. I had the same comment as adrianschmutzler.  just noticed the commit
Feb 25 16:42:32 <ldir> yes, total brainfart.  Am so out of practice messing with this stuff.
Feb 25 16:46:34 <adrianschmutzler> I wonder how we should deal with ramips kernel bump. Since it's already a never-ending-story for 4.19, I really ask myself whether it wouldn't be easier to bump it per-subtarget.
Feb 25 16:52:12 <ldir> fixed.
Feb 25 16:56:20 <ldir> thanks for the pointers/corrections
Feb 25 17:59:57 <mirko> what's the best way to reliably figure out where the squashfs part of a partition(image) ends?
Feb 25 18:00:23 <mirko> alternatively (if not the same): figuring out where the overlayfs starts
Feb 25 18:20:27 <blogic> mirko: by looking at the result o the mtd splitter ?
Feb 25 18:47:02 <blogic> xback: https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/for_koen
Feb 25 19:22:06 <xback> blogic: thanks
Feb 25 19:25:02 <xback> i'll need to rebase that work again as it conflicts with your own Mediatek path you pushed to master ;-)
**** ENDING LOGGING AT Tue Feb 25 19:26:28 2020

**** BEGIN LOGGING AT Wed Feb 26 12:53:04 2020
Feb 26 13:02:00 <guifipedro[m]> ping jow https://github.com/openwrt-routing/packages/issues/548 https://github.com/openwrt-routing/packages/pull/552 (easy resolution, right?)
Feb 26 13:11:44 <zorun> any comments on LuCI for the 19.07.2 release notes? https://openwrt.org/releases/19.07/notes-19.07.2
Feb 26 13:12:10 <zorun> I didn't follow closely this splice/stalling issue, but if it's fixed it's probably worth talking about it
Feb 26 13:12:26 <jow> I need to cherry-pcik that uhttpd fix yet
Feb 26 13:12:46 <jow> however I have the feeling there's still lurking ustream / ssl / uhttpd deadlock issues
Feb 26 13:12:53 <zorun> ok
Feb 26 13:13:36 <jow> however the fix does indeed help, the changelog item should be something like "improved reliability for uhttpd https requests under load"
Feb 26 13:13:59 <zorun> thanks
Feb 26 13:14:30 <karlp> I think https://openwrt.org/releases/19.07/notes-19.07.2#known_issues should get "umdns no longer works" listed.
Feb 26 13:15:22 <zorun> is that a regression from 19.07.1?
Feb 26 13:15:25 <karlp> yes.
Feb 26 13:16:28 <adrianschmutzler> Please remove the MR3420 v2 from the fixes list.
Feb 26 13:16:47 <adrianschmutzler> That one is only in the commit title, but the device is not present in 19.07
Feb 26 13:17:31 <adrianschmutzler> in Device support section
Feb 26 13:18:24 <zorun> thanks, done
Feb 26 13:20:28 <cp-> nbd: it broke my configurations before
Feb 26 13:20:39 <cp-> nbd: and not only a bit
Feb 26 13:20:42 <zorun> karlp: I added a note with a link to https://openwrt.org/docs/guide-developer/mdns (is that the right page?)
Feb 26 13:20:46 <guifipedro[m]> anyone with a nanostation m5 xw to reproduce this bug? https://bugs.openwrt.org/index.php?do=details&task_id=2848
Feb 26 13:21:07 <zorun> guifipedro[m]: did you backport your bmx fixes to the 19.07?
Feb 26 13:21:11 <zorun> I can merge them if you want
Feb 26 13:22:07 <karlp> zorun: you can link to the bug report with fix if you like too: https://bugs.openwrt.org/index.php?do=details&task_id=2833
Feb 26 13:22:10 <guifipedro[m]> zorun: are you talking about https://github.com/openwrt-routing/packages/issues/548 https://github.com/openwrt-routing/packages/pull/552 ?
Feb 26 13:22:45 <guifipedro[m]> https://bugs.openwrt.org/index.php?do=details&task_id=2833 is a more general thing, I think it's still not oficially confirmed and may affect other devices and other routing protocols
Feb 26 13:23:41 <zorun> guifipedro[m]: yes, the simple fixes for LuCI
Feb 26 13:24:16 <karlp> guifipedro[m]: 2833 is what breaks umdns, which is what I linked it for.
Feb 26 13:24:42 <karlp> I would not be surprised if other things are broken too.
Feb 26 13:24:59 <guifipedro[m]> the simple fixes for LuCI, yea, go ahead. I tried to add that patches to my image builder and failed (see my comment in https://github.com/openwrt-routing/packages/issues/548, maybe you have an answer)
Feb 26 13:25:00 <guifipedro[m]> zorun: ^
Feb 26 13:25:19 <guifipedro[m]> karlp: ok! thanks! where is the activity of this bug report going on?
Feb 26 13:26:02 <guifipedro[m]> karlp: I might help, but I am a bit lost. It was working on 18.x release and stopped working in 19.x, right? So we have to find which commit introduced the bug
Feb 26 13:29:12 <zorun> ah, so it's a regression with libubox? this looks bad indeed :/
Feb 26 13:32:36 <zorun> I've also added a note on https://openwrt.org/releases/18.06/notes-18.06.8
Feb 26 13:38:02 <guifipedro[m]> I think is not the same issue I'm talking about. My case is more generic because you don't receive a respond in ff02::2%<iface> and that only applies to devices with internal switch.
Feb 26 13:38:24 <guifipedro[m]> next thing I will try with tp-link 4300 if I reproduce there the bug too
Feb 26 13:44:00 <jow> did anyone recently test openwrt master with multiple ssids?
Feb 26 13:44:37 <jow> apparently the network.wireless status output is incomplete... entries for the 2nd, 3rd etc. interface on a phy lack the "ifname" property
Feb 26 14:35:26 <nmrh> hmm, ipq806x snapshot for tue feb 25 (via imagebuilder), wifi is not working
Feb 26 14:35:39 <nmrh> mon feb 24 snapshot via imagebuidler, it was fine
Feb 26 14:36:41 <nmrh> ath10k-ct-htt firmware, likely clue from dmesg is:
Feb 26 14:36:45 <nmrh> [   44.628614] ath10k_pci 0001:01:00.0: mac-vif-chan had error in htt_rx_h_vdev_channel, peer-id: 0  vdev-id: 0 peer-addr:
Feb 26 14:37:19 <nmrh> device is r7500v2
Feb 26 14:40:19 <nmrh> is the above a question for greearb_ or someone else?
Feb 26 14:58:11 <nmrh> i got to roll back to get wifi working, I'll post on the forums in a bit
Feb 26 15:01:54 <adrianschmutzler> jow: I've just accidentally pushed a new branch "boardname" to official git. As I cannot not delete it through the same way, I hope you can?
Feb 26 15:02:08 <adrianschmutzler> https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/boardname
Feb 26 15:03:05 <jow> sure, give me minute
Feb 26 15:03:18 <adrianschmutzler> thanks, and sorry.
Feb 26 15:03:45 <adrianschmutzler> maybe one should put the same blocker that prevents deleting branches to adding branches
Feb 26 15:04:24 <jow> should be gone
Feb 26 15:04:34 <adrianschmutzler> perfect, thanks.
Feb 26 15:05:41 <adrianschmutzler> I deleted it from GitHub manually.
Feb 26 15:06:01 <jow> ah yes. next push should've wiped it on github too
Feb 26 15:06:22 <adrianschmutzler> btw, should we add 19.07 to "branch protection rules" there?
Feb 26 15:07:29 <adrianschmutzler> Hmm, nothing is checked there, might be a remnant ...
Feb 26 15:07:45 <adrianschmutzler> Settings->Branches
Feb 26 15:09:59 <jow> adrianschmutzler: yep, please
Feb 26 15:10:32 <jow> however since openwrt/openwrt on github is just a mirror, any local changes there will be wiped anyway wghen someone pushes to git.openwrt.org
Feb 26 15:21:04 <adrianschmutzler> ah, now I understand it. The checkboxes are only if you want to deviate from the default protection settings. I added 19.07.
Feb 26 15:33:32 <jow> ynezz: did you merge all the things for 19.07 ?
Feb 26 15:33:48 <jow> or is there outstanding stuff in your staging tree?
Feb 26 15:34:17 <jow> nvm, it seems the stuff is in
Feb 26 15:34:38 <jow> that leaves the libubox breakage
Feb 26 15:34:45 <adrianschmutzler> didn't you want to add the CVE reference?
Feb 26 15:34:55 <jow> oh yes, totally forgot
Feb 26 15:42:36 <jow> done
Feb 26 15:50:29 <adrianschmutzler> I've decided to push the Loco M XW as well.
Feb 26 15:50:48 <adrianschmutzler> zorun: Can you add it to the new devices list in the release notes?
Feb 26 15:58:29 <jow> ynezz: I decided to look into that libubox issue tonight, I don't want to release a known broken version
Feb 26 15:58:53 <jow> if that means to delay the tagging until tomorrow then its worth the wait imho
Feb 26 15:59:24 <jow> normally I'd say we could just push out a fixed package later but with libubox being such a core component...
Feb 26 16:00:28 <adrianschmutzler> does it affect 18.06 as well? otherwise you could consider tagging (and starting building) that already if it helps
Feb 26 16:01:21 <jow> good question
Feb 26 16:01:49 <adrianschmutzler> so, that answer tells me 18.06 should wait as well ;-)
Feb 26 16:02:07 <zorun> yes, according to the bug report (FS#2833)
Feb 26 16:02:25 <zorun> 18.06 received libubox backports in 18.06.7
Feb 26 16:02:29 <zorun> adrianschmutzler: sure, will do
Feb 26 16:04:28 <jow> adrianschmutzler: yeah from a quick look at the backport commit I'd tend to believe that it has similar issues
Feb 26 18:50:44 <stintel> https://www.welivesecurity.com/wp-content/uploads/2020/02/ESET_Kr00k.pdf
Feb 26 20:38:12 <mangix> stintel: broadcom specific
Feb 26 20:38:31 <mangix> they don't implement mac80211 stuff AFAIK
Feb 26 22:17:10 <Hauke> is brcmfmac and its FW affected by the securoty problem stintel mentioned?
Feb 26 23:45:14 <mangix> Hauke: Without knowning any of the details, I lean towards yes.
Feb 26 23:47:34 <mangix> jow: I've probably asked this before, but what's the point in the libiconv stub? It seems to me to be used for uClibc-ng only, which is marked as BROKEN.
**** ENDING LOGGING AT Thu Feb 27 02:59:58 2020