**** BEGIN LOGGING AT Wed Aug 05 02:59:57 2020
**** BEGIN LOGGING AT Wed Aug 05 04:39:53 2020
Aug 05 05:43:56 <blogic> dwmw2_gone: santa just dropped me a file
Aug 05 06:31:09 <blogic> dwmw2_gone: please git pull to get the files
Aug 05 06:42:22 <rmilecki> nbd: can you take a look at [PATCH uhttpd rfc] client: really close connection on timeout https://patchwork.ozlabs.org/project/openwrt/patch/20200727181444.28780-1-zajec5@gmail.com/
Aug 05 07:04:07 <mangix> jow: what happened with https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=32ccb118f2f31537baa1ea03627f27911bc857f2 ?
Aug 05 07:23:42 <jow> mangix: nothing?
Aug 05 07:36:18 <dwmw2_gone> blogic: shiny. thanks.
Aug 05 07:56:38 <rmilecki> jow: i found sth interesting in https://html.spec.whatwg.org/multipage/server-sent-events.html#event-stream-interpretation regarding MessageEvent
Aug 05 07:56:53 <rmilecki> "Initialize event's (...) lastEventId attribute to the last event ID string of the event source."
Aug 05 07:57:33 <rmilecki> this sounds like something more reliable than reading EventSource.lastEventId
Aug 05 07:58:25 <rmilecki> jow: one minor issue I realized is that EventSource does not allow sending custom Authorization: header, so we'll need to pass token as GET parameter I think
Aug 05 08:02:11 <jow> rmilecki: that would be very ugly
Aug 05 08:02:27 <rmilecki> oh
Aug 05 08:04:28 <jow> rmilecki: but it seems it is the only way
Aug 05 08:10:40 <nick[m]3> can't you edit a task on openwrt bug tracker?
Aug 05 08:10:41 <nick[m]3> https://bugs.openwrt.org/index.php?do=details&task_id=3272
Aug 05 08:12:55 <Borromini> nick[m]3: not that i know of... need to comment
Aug 05 08:15:21 <nick[m]3> Borromini: okay shit. now the task looks ugly ~.~ just wanted to save what I wrote and added...
Aug 05 08:15:31 <Borromini> i know the feeling :P
Aug 05 08:19:09 <nick[m]3> svanheule: PaulFertser I added a task for the jffs2 issue https://bugs.openwrt.org/index.php?do=details&task_id=3272
Aug 05 08:19:18 <nick[m]3> sadly, the layout looks bad
Aug 05 08:27:25 <Borromini> nbd: i have opened a topic about the mt7612 5 GHz radio crapping out https://forum.openwrt.org/t/5-ghz-wlan-craps-out-upon-radar-detection-start-dfs-cac-failed/71018
Aug 05 08:27:41 <Borromini> i'm not sure if this is a hostapd or a driver issue.
Aug 05 08:35:59 <Grommish> So, I'm trying to bring up a rust lang package.. I've got it working, with the exception that I need to set two host variables so that the build system see's them..  any suggestions on how to do that?
Aug 05 08:38:48 <PaulFertser> nick[m]3: tbh, from your description it's not clear when exactly the problem appears and whether jffs2 overlay ever works at all.
Aug 05 08:41:47 <PaulFertser> nick[m]3: I think if the flash wasn't unlocked then sysupgrade wouldn't be able to write new kernel and rootfs too.
Aug 05 08:45:06 <nick[m]3> PaulFertser: yeah. Actually, I wanted to add a more detailed description but I can not edit this bug report anymore :/ And yes, it should be called unlocking mtd device
Aug 05 08:46:50 <PaulFertser> nick[m]3: it's ok to add relevant info in ticket comments.
Aug 05 09:22:15 <svanheule[m]> nick: Maybe it's worth mentioning in the ticket that 4.14 doesn't have any issues.
Aug 05 09:22:42 <svanheule[m]> nick: maybe it's also worth mentioning that on 4.14 there are no issues
Aug 05 09:25:04 <nick[m]3> svanheule: added. I just went from 4.19 -> 5.4 without "-n" and it seems to work.
Aug 05 09:25:38 <svanheule> nick: Good, you did get the message (app.element.io claims it's not connected...)
Aug 05 09:26:19 <nick[m]3> svanheule: which message? that I should add 4.14? yep
Aug 05 09:26:38 <svanheule[m]> Yeah, that one. I see it's now sent twice...
Aug 05 09:29:49 <svanheule[m]> nick: Maybe also useful to note what you mean by "it works on". If I recall correctly, 4.14: jffs2 initialisation worked and sysupgrade (?), 4.19: only sysupgrade (not with -n), 5.4: syupgrade?
Aug 05 09:30:37 <svanheule[m]> I believe some of the issues with 4K erases were introduced in OpenWrt with 4.19
Aug 05 09:32:20 <svanheule[m]> PaulFertser: I agree that it's strange sysupgrade would work, but jffs2 init wouldn't if unlocking was the actual root cause
Aug 05 09:33:05 <svanheule[m]> But then again, I don't know the code, so I can't tell if the code paths would be similar
Aug 05 09:35:01 <adrianschmutzler> stupid question: if ath79 has CONFIG_LEDS_GPIO=y in kernel config, then all cases of kmod-leds-gpio can be dropped?
Aug 05 09:36:22 <nick[m]3> svanheule: yesterday I wanted to install some community mesh networking image. So I compiled with 5.4 and flashed it directly from airos. Afterwards I did sysupgrade the sysupgrade image again. Suddenly after a reboot I was not able to login since the root password changed to something that I did not type (so data corruption). Then I did 4.19 and sysupgrade 4.19 from airos (cause I was not able to login again) and it
Aug 05 09:36:23 <nick[m]3> worked. Today I want from 4.19 to 5.4 again with saving of the config files.
Aug 05 09:39:48 <svanheule[m]> nick: Sounds like useful details to add to the ticket :-)
Aug 05 09:44:06 <nick[m]3> svanheule: added
Aug 05 09:48:38 <nick[m]3> svanheule: I hope I will find someone with the same SOC that can reproduce the issue
Aug 05 09:49:11 <svanheule[m]> nick: This doesn't happen on other UBNT devices?
Aug 05 09:49:36 <nick[m]3> I don't have any other UBNT device
Aug 05 09:49:48 <nick[m]3> but there is a similar issue for the lightbeam ac gen 2
Aug 05 09:50:57 <svanheule[m]> Same SoC/flash?
Aug 05 09:51:41 <nick[m]3> svanheule: the soc is a bit different "Atheros AR9342-BL1A" so this BLA1A,
Aug 05 09:52:19 <nick[m]3> in openwrt page this is written "The above upgrade procedure left the filesystem in a slightly damaged state (i.e. changes are lost after reboot). This is indicated by kernel messages (dmesg) related to jffs2_scan_eraseblock. Another firmware upgrade fixes this."
Aug 05 09:52:24 <nick[m]3> so this is a very similar issue
Aug 05 09:57:03 <svanheule[m]> nick: Also a Macronix flash chip "mx25l12805d"
Aug 05 09:58:12 <svanheule[m]> nick: I was trying to see if I could order some macronix flash to see if it's reproducible on my devices, but I can't find that specific type (seems to be a bit older)
Aug 05 10:02:48 <nick[m]3> svanheule: https://bugs.openwrt.org/index.php?do=details&task_id=1547
Aug 05 10:04:29 <nick[m]3> svanheule: Do u believe chaing the dts file with https://github.com/openwrt/openwrt/pull/1026/files#diff-1867c4fc25ff4ed9bfd31573de848d01R18 works?
Aug 05 10:07:07 <nick[m]3> there is more than 1 device with the same soc that is adding that line
Aug 05 10:07:16 <nick[m]3> to the device tree
Aug 05 10:08:34 <svanheule[m]> nick: that wndr3800 might have been something else. The rootfstype kernel arg was provided twice, so it might be that the squashfs was being parsed as jffs2
Aug 05 10:08:48 <nick[m]3> "Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jffs2" ... already in my bootlog
Aug 05 10:09:06 <svanheule[m]> nick: and the bootargs line was recently merged into a common source file, so you don't need that anymore
Aug 05 10:26:09 <PaulFertser> nick[m]3: have you tried lowering the spic clock just in case?
Aug 05 10:26:44 <nick[m]3> PaulFertser: no, can I do this without modifying the dts file?
Aug 05 10:28:16 <PaulFertser> nick[m]3: I do not think so. It's fixed in dts.
Aug 05 10:30:51 <rmilecki> jow: one more thing to consider...
Aug 05 10:31:09 <rmilecki> jow: fetch() with response.body that is ReadableStream
Aug 05 10:31:15 <rmilecki> https://developer.mozilla.org/en-US/docs/Web/API/Body/body and https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream
Aug 05 10:31:25 <rmilecki> it seems to be supported by Fx, Chromium, Edge
Aug 05 10:31:50 <rmilecki> someone wrote events on top of that: https://medium.com/@rob.blackbourn/beyond-eventsource-streaming-fetch-with-readablestream-5765c7de21a1
Aug 05 10:34:23 <rmilecki> jow: it basically allows reading bytes as stream, then you can treat them as characters
Aug 05 10:34:35 <rmilecki> you can use character to parse JSON or another custom text format
Aug 05 10:34:59 <rmilecki> you can just JSON to carry ubus notification
Aug 05 10:35:46 <rmilecki> you could probably even try passing blob as stream, but I really don't want that ;)
**** BEGIN LOGGING AT Wed Aug 05 10:45:10 2020
Aug 05 10:45:53 <nick[m]3> PaulFertser: can u give me a value for lowering the spi clock?
Aug 05 10:46:32 <PaulFertser> nick[m]3: I'd try 10 MHz
Aug 05 10:46:49 <nick[m]3> PaulFertser: k :)
Aug 05 11:15:05 <jow> rmilecki: yeah, but EventSource is there and nicelywraps up all this in a native manner
Aug 05 11:17:53 <jow> rmilecki: I guess we have to live with passing the token via query param. But we should consider some kind of derived token which one can obtain by calling another endpoint, in order to avoid exposing the session secret itself in the query string
Aug 05 11:18:41 <jow> rmilecki: but given that subscription acl handing is not implemented anyway atm I see this as a topic for the next iteration
Aug 05 11:20:17 <jow> rmilecki: EventSource() will sent cookies along with its request though, so maybe we can also consider cookie authnetication for the ubus-rpc
Aug 05 11:20:35 <jow> like luci does
Aug 05 12:52:11 <Bumble-Bee> blogic: the ax feed fails a lot due to missing mhi drivers in current 5.4
Aug 05 13:04:22 <rmilecki> jow: ok, thanks for comments
Aug 05 13:04:57 <rmilecki> jow: so I'll probably just wait for your testing now, as none of discussed things stops V2 at this point
Aug 05 13:05:09 <rmilecki> jow: i'll send reply not to forget what we discussed
Aug 05 14:28:44 <blogic> Bumble-Bee: i wont repeat myself ;)
Aug 05 14:31:04 <Bumble-Bee> blogic:  know I know, i did get it building in the end with the same results. I'll wait for the rest of your changes to be pushed and hide the ax3600 so I can't play with it anymore
Aug 05 14:34:55 <blogic> you can disable ath11k-pci and then you probably wont see the mhi issue
Aug 05 14:37:40 <Bumble-Bee> Yeah that's what I did, but with that hostap thinks the AP comes online but no AP can be seen. I'm guessing I'm missing something somewhere else in the kernel.
Aug 05 14:45:14 <adrianschmutzler> blogic: what's your plan for ipq807x in 20.xx? Should we keep it source-only there or remove it again for the stable branch?
Aug 05 15:20:52 <blogic> adrianschmutzler: remove it from the 20.07 branch
Aug 05 15:47:19 <Bumble-Bee> blogic: did you say you have the AX3600 and AX1800 ?
**** BEGIN LOGGING AT Wed Aug 05 15:50:41 2020
Aug 05 16:23:27 <blogic> ax3600 is here and ax1800 ordered
Aug 05 16:37:36 <karlp> jow: any opinion on https://github.com/openwrt/luci/pull/4240 ? we spoke about it a bit beforethe summer holidays?
**** BEGIN LOGGING AT Wed Aug 05 20:00:49 2020
Aug 05 20:06:44 <aparcar> nbd: can you please check my mkhash patches?
Aug 05 21:05:18 <Grommish> Anyone take a look at this Makefile I'm working up for Rust? https://hastebin.com/yafeceqide.makefile  You can see what I am needed it to do, but I can't get it to trigger properly :(
Aug 05 21:06:37 <Grommish> Tells me nothing to be done for compile, and doesn't call configure or install..
**** BEGIN LOGGING AT Wed Aug 05 21:20:16 2020
Aug 05 21:44:53 <rsalvaterra> aparcar: ping?
Aug 05 23:43:02 <aparcar> Grommish: it does some stuff here
Aug 05 23:43:24 <aparcar> I think it doesn't really need BUILD_DIR etc stuff
Aug 05 23:43:37 <Grommish> Nothing gets installed in the image
Aug 05 23:43:43 <Grommish> it's entirely host based
Aug 05 23:43:49 <aparcar> I know
Aug 05 23:43:50 <Grommish> which is why I put it in hostpkg
Aug 05 23:44:26 <aparcar> https://paste.debian.net/1159285/
Aug 05 23:44:50 <Grommish> Yep
Aug 05 23:44:52 <Grommish> But
Aug 05 23:45:37 <aparcar> It's bad that stuff is written to /home/user/.rustup
Aug 05 23:45:41 <Grommish> It isn't
Aug 05 23:45:47 <Grommish> YOUR rust is
Aug 05 23:46:06 <Grommish> Which is why i use $(BUILD_DIR_HOST)
Aug 05 23:46:17 <Grommish> Rustup by default goes to $HOME/.cargo
Aug 05 23:46:33 <Grommish> I send it to $(BUILD_DIR_HOST)/.cargo to keep it contained inside openwrt
Aug 05 23:46:41 <aparcar> good
Aug 05 23:46:48 <Grommish> which goes to build_dir/hostpkg/
Aug 05 23:46:55 <Grommish> But, while the first run works
Aug 05 23:46:57 <Grommish> sorta
Aug 05 23:46:58 <aparcar> but from the build log it looks like doing stuff outside
Aug 05 23:47:09 <Grommish> it doesn't keep the PATH
Aug 05 23:47:23 <Grommish> so when I go to use rustc/cargo (like with my suricata package) it fails to find it
Aug 05 23:49:19 <Grommish> https://hastebin.com/jazujicaqa.bash  here is what a full compile run gives
Aug 05 23:49:31 <Grommish> At least the rustup part
Aug 05 23:50:28 <swalker> stuff a true statement in the install section?
Aug 05 23:50:44 <Grommish> https://hastebin.com/yafeceqide.makefile
Aug 05 23:51:41 <swalker> is this only a build depends for suricata?
Aug 05 23:52:20 <Grommish> For me? Yah..  But in order to submit a PR for suricata, it'll require a rustc lang package
Aug 05 23:52:25 <Grommish> because it has to be self-contained
Aug 05 23:52:52 <Grommish> Plus, it seemed like a fun idea to toss in rust support hehe
Aug 05 23:53:05 <aparcar> Grommish: where is your suricata makefile?
Aug 05 23:53:07 <Grommish> I got suricata running by having a local rust install
Aug 05 23:54:03 <Grommish> https://hastebin.com/pagegezugo.makefile
Aug 05 23:59:44 <aparcar> Grommish: so suricata internally runs cargo?
Aug 06 00:00:22 <Grommish> Nope
Aug 06 00:00:29 <Grommish> Suricata calls rustc/cargo, yes
Aug 06 00:00:33 <Grommish> during it's compile
Aug 06 00:00:36 <Grommish> but not after install
Aug 06 00:00:56 <Grommish> If I call rustup/configure, it's fine
Aug 06 00:01:02 <Grommish> but it fails to maintain the path
Aug 06 00:01:17 <Grommish> so by the time suricata comes around, rustc isn't found
Aug 06 00:01:56 <Grommish> https://hastebin.com/okufefohaq.coffeescript
Aug 06 00:03:49 <Grommish> Ideally, the Host/Install stuff on teh rustup would be run during Host/Configuration or Compile
Aug 06 00:04:05 <Grommish> so that the target toolchain is installed along with the host one
Aug 06 00:04:49 <aparcar> Grommish: I think you want to install bist rust and cargo into staging_dir/host/bin
Aug 06 00:05:21 <Grommish> Ok.. I'll look for the variables for it
Aug 06 00:05:30 <Grommish> well
Aug 06 00:05:44 <Grommish> Is there anyway to add the .cargo/bin directory to the PATH that openwrt uses?
**** BEGIN LOGGING AT Thu Aug 06 00:07:44 2020
Aug 06 00:07:44 <Grommish> I was looking at golang for some of the host target stuff
Aug 06 00:24:43 <Grommish> aparcar: https://github.com/openwrt/packages/pull/13040
Aug 06 00:58:02 <aparcar> Grommish: thanks
Aug 06 02:01:19 <swalker> RUSTUP_HOME=$(HOST_RUST_DIR) CARGO_HOME=$(HOST_CARGO_DIR) $(HOST_CARGO_DIR)/bin/rustup target add $(RUSTC_TARGET_ARCH) ...
Aug 06 02:09:24 <swalker> -> https://pastebin.com/raw/eU9QRS1n
Aug 06 02:51:35 <Grommish> swalker: appreciate..  I'll take a look at it!
Aug 06 02:58:06 <owrt-snap-builds> build #425 of mpc85xx/p1020 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/425  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Alexey Dobrovolsky <dobrovolskiy.alexey@gmail.com>, Tobias Welz <tw@wiznet.eu>
Aug 06 02:59:41 <owrt-snap-builds> build #422 of ramips/rt305x is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/422  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Alexey Dobrovolsky <dobrovolskiy.alexey@gmail.com>, Tobias Welz <tw@wiznet.eu>
**** ENDING LOGGING AT Thu Aug 06 02:59:57 2020