**** BEGIN LOGGING AT Tue Dec 08 02:59:57 2020 Dec 08 04:45:04 Hey, does anyone here have experience porting Freescale powerpc boards? Dec 08 04:45:43 I'm working on the P2041RDB and I used 5de6aed42c (mpc85xx: add support for Freescale (NXP) P2020RDB) as a starting point Dec 08 04:45:56 but sadly I'm getting a machine check exception when attempting to u-boot the initramfs that results. Dec 08 04:46:07 and I don't know how to read powerpc assembly :) Dec 08 04:46:18 or, well. No. PowerPC machine code :( Dec 08 04:48:03 hurricos: I've attempted to get something running on a P1020 based Aerohive AP370, and it runs fine, but sysupgrade is having issues with nand bad blocks offsets... Dec 08 04:48:10 do you have a pastebin of what you are seeing ? Dec 08 04:48:50 Isn't the AP370 basically a souped up AP330? Dec 08 04:49:47 yeah, pretty much, I've managed to fry one though and doesn't even get to u-boot anymore... not sure what is going on with the boot process, so will need to JTAG once I have some time Dec 08 04:50:26 blocktrron: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=blobdiff;f=tools/zstd/Makefile;h=f474cb856460c19ed05cb5d947768008eed22db0;hp=7459725e8e79b846ed96551753d07fdd02459598;hb=c261a066f15e5399ee318e5eb2b98510f6e5be0d;hpb=0bcf25cf481334552edb19dbea342bce697b3850 the original URL has always been wrong. The GITHUB macro is not used correctly here. Dec 08 04:50:29 here it is: https://pastebin.com/uCqgUSP8 Dec 08 04:51:12 blocktrron: I would use the same URL as here: https://github.com/openwrt/packages/blob/master/utils/zstd/Makefile#L8 Dec 08 04:52:12 well, use the gz file instead of the zstd one Dec 08 04:56:34 hurricos: have you tried loading the kernel and DTS separately ? Load Address of 0xc0000000 may not be a good choice if it relocates ? Dec 08 04:56:36 OK, got something! I tried a different memory region and got past it. It must have been because OpenWrt 32 bit PowerPC wants to limit RAM to 3GB Dec 08 04:56:38 yeah Dec 08 04:57:17 echo $((0xc0000000/2**20)) is telling Dec 08 05:01:28 I do currently load the kernel and dts separtely. Looks like I need to hunt some bugs with the dts ... Dec 08 05:01:38 How does the AP330 get the fdt compiled? Dec 08 05:02:01 I think I need to build a separate one than the one the vendor provides. Dec 08 05:02:11 WARNING: could not find compatible node fsl-usb2-mph or fsl-usb2-dr: FDT_ERR_NOTFOUND. Dec 08 05:03:18 i took the AP330 DTS, and the factory DTS, and merged the two, based on the latest kernel Dec 08 05:03:55 that uboot looks like it should support fdt print Dec 08 05:04:52 so, ftd addr 0xc00000; ftd print should give you something to work with Dec 08 05:05:14 Oh yeah Dec 08 05:05:51 awesome Dec 08 05:06:29 alright, time to get some sleep first. but encouraging! Dec 08 05:06:29 then, look at each of the compatible lines, and see whether it still exists in 5.4.81, and modify to the newer one Dec 08 05:06:41 oh yeah the original running kernel is um Dec 08 05:06:44 3.0 :) Dec 08 05:06:53 yup, so tweaking necessary Dec 08 05:07:06 I was thinking though. This board actually comes with a dts Dec 08 05:07:09 vendor-provided Dec 08 05:07:22 In the vendor's SDK, in OpenWrt Dec 08 05:07:50 well, it's loaded in memory anyway, so you can just dump what's there, which would match the dts in the vendor SDK Dec 08 05:07:56 so basically what I'm wondering is, how do I compile that into an fdt which I can load up Dec 08 05:08:01 I think the vendor's is newer than this board is Dec 08 05:08:06 ah ok Dec 08 05:08:10 like significantly Dec 08 05:08:14 this was built in .... 2012 Dec 08 05:08:16 :( Dec 08 05:08:55 if you want to do it properly, you can use my aerohive ap370 PR as a basis to get the build building the necessary stuff Dec 08 05:09:10 otherwise, you can manually compile the DTB with dtc -I dts -O dtb ... Dec 08 05:09:37 https://github.com/openwrt/openwrt/pull/3293 Dec 08 05:10:29 Thanks! Yeah this looks good Dec 08 05:10:39 man am I glad this board has 1Gb SPI NOR :) Dec 08 05:10:43 and not NAND LOL Dec 08 05:11:00 best of luck, thanks for the help @tusker! Dec 08 05:12:08 no worries :) Dec 08 07:47:02 Whose up that and has an opinion on how packages or software in general should behave. Bonus points if the opinion fits into the OpenWrt framework, but I'll take the under if I have to Dec 08 07:53:02 stintel: sps30 data http://ynezz.true.cz/temp/pms.json.gz Dec 08 07:56:11 aparcar[m]: I'll rebase before pushing Dec 08 08:40:23 ynezz: thanks Dec 08 09:59:49 nbd, ping Dec 08 10:00:35 nitroshift: pong Dec 08 10:04:56 nbd, pm? Dec 08 10:11:07 anyone had their hands on a ubnt bullet ac? Dec 08 11:38:26 stintel: https://marc.info/?l=linux-wireless&m=160742701104623&w=4 :P Dec 08 11:42:49 rsalvaterra: for the reference, the Intel devs usually monitor the kernel bugzilla and ucode crashes are eventually fixed when reported there. It just takes loooong time Dec 08 11:44:01 Wow, someone's actually looking at the kernel bugzilla…? O_o Dec 08 11:44:33 My experience is that bugs just die of old age there… Dec 08 11:44:50 rsalvaterra: intel listens Dec 08 11:45:00 qualcomm does not Dec 08 11:46:09 Oh, well… I just mailed Luca Coelho and Johannes Berg directly… Dec 08 11:46:47 t Dec 08 11:47:05 I remember correspondance with the former Dec 08 12:04:58 do we care to fix that? https://bugs.openwrt.org/index.php?do=details&task_id=3492 Dec 08 12:05:17 I thought this is expected. But I lost track of the 64k sector thing Dec 08 12:05:38 as long as this is a one-time transition thing I'd consider it a wontfix Dec 08 12:05:45 same as non-DSA to DSA migration Dec 08 12:06:04 especially since we're not talking about bricks but about losing settings, so it is acceptable imho Dec 08 12:41:15 jow: well, that 4k sector problem will essentially affect all mikrotik devices Dec 08 12:41:52 so, they won't be much fun to use now Dec 08 12:43:27 but this discussion is going on for half a year now at least, and despite john-tho's attempts to fix the issue, it doesn't seem like anybody from the maintainer side is interested (even upstream, if I remember correctly - nobody even answered on his patch there) Dec 08 12:53:45 does the 4k problem affect nor or nand flash? Dec 08 12:54:35 in that case, nor Dec 08 13:21:18 How are hotplug.d/neigh triggered? I thought it would be triggered by maybe when the kernel adds something to "ip -4 neigh". But it doesn' Dec 08 13:54:43 Hi people is OpenWrt 19.07.5 ready? Dec 08 13:55:08 There has bin no email about it but there is a post in the forums. Dec 08 13:55:28 and what about 18.06.9 Dec 08 13:56:15 Should i post about it on the openwrt twitter or what? Dec 08 14:01:28 Tapper: it's not ready, do you have a link to the post? Dec 08 14:19:21 jow: can you look into https://patchwork.ozlabs.org/project/openwrt/patch/20201109070922.23088-1-rosenp@gmail.com/ ? It's needed for updating conntrack-tools Dec 08 14:58:12 zorun https://forum.openwrt.org/t/openwrt-19-07-5-rolling-out/81479 Dec 08 15:07:14 openssl 1.1.1i is out Dec 08 16:15:26 jow: is https://openwrt.org/docs/techref/luci2 still relevant/updated for the new luci you're working on? any doc about the new luci in master branch other than the client-js-api pages? Dec 08 16:21:17 rr123: if you want to amuse yourself while you wait, -> https://github.com/openwrt/luci/blob/b496350bbcd9892502df6d5e51ef04d1265d5e98/themes/luci-theme-bootstrap/htdocs/luci-static/bootstrap/cascade.css Dec 08 16:22:01 (will probably eventually end up as a new theme instead of replacing existing bootstrap theme) Dec 08 16:23:25 dorf: that's a css file, not a design overview though, what about boostrap5 for the css... Dec 08 16:23:57 well spotted! boostrap? Dec 08 16:24:04 is that a naming proposal? Dec 08 16:24:58 not a frontend guy but once a while need tweak the UI a bit which gave me headaches :( Dec 08 16:25:36 yeah, it is headache inducing, and I am a front end guy :) Dec 08 16:25:52 rebootstrap Dec 08 16:26:14 that's already on file as a contender, Tapper, worry not :) Dec 08 16:26:41 Nice! It would make me happy to have it named rebootstrap. Dec 08 16:26:58 what about boobstrap? Dec 08 16:27:01 * dorf hides. Dec 08 16:27:10 I would do a litel dance and everything! Dec 08 16:27:23 hahahahahaha Dec 08 16:28:21 https://getbootstrap.com/docs/5.0/content/reboot/ reboot is already used by bootstrap, so rebootstrap will make people dizzy Dec 08 16:28:22 only on the condition that cockstrap is also nominated Dec 08 16:28:53 * dorf lols Dec 08 16:32:42 currently new luci will poll constantly, chrome devtools xhr will be flooded by them, what about doing the xhr with websockets instead of ajax calls Dec 08 16:33:15 i have no idea how websockets calls will be authenticated though Dec 08 16:33:17 whilst I'm all for puerile schoolboy humour I also think that we shouldn't discourage women from our ranks Dec 08 16:33:19 Hi can some one give me the Logo URL for OpenWrt? Dec 08 16:33:53 ldir-: absolutely. apologies if my inane comment caused any offense. Dec 08 16:34:11 * rr123 feels europe has already been managed by ladies in the government, usa is catching up Dec 08 16:34:40 rr123 good Dec 08 16:35:20 rr123: if web sockets make less demands of the browser, I'm all for them. Dec 08 16:36:12 Any one have the Logo URL? Dec 08 16:36:14 https://dev.iopsys.eu/iopsys/owsd https://github.com/mkschreder/orangerpcd both approaches are using websockets for openwrt webui Dec 08 16:36:22 there are places where ajax can effectively hang the browser, specifically the realtime graphs -> connections page. Dec 08 16:36:41 I am going to set up a OpenWrt folding at home team. Dec 08 16:37:17 no no, not at all - it just got me thinking - openwrt strikes me as a very male 'hobby'. Dec 08 16:37:40 ldir Yeah Dec 08 16:38:32 ldir I like to see a female name around the place. If I ever do spot one I never say anything tho just incase I am rong. Dec 08 16:38:57 dorf: i began to study websocket yesterday, i feel the new luci is still luggish a bit sometimes, offload cpu from the target did not help a lot, so it could be related to design, embedded board sometimes run long-time calls which incur polls, websocket can help there Dec 08 16:39:20 ldir and it's mad even when gamming or posting on a from if you use a girls name you get tretted difrent. Dec 08 16:39:29 s/luggish/sluggish/ Dec 08 16:39:46 gaming* Different* Dec 08 16:40:23 rr123: yeah, I hear you. I'm not entirely convinced ajax is the way to , either, or indeed handing everything off to javascript, but I'm not the one making the call. Dec 08 16:40:37 treated* forums* Dec 08 16:40:50 Seems to me there's plenty of content in LuCI that could just as well be rendered statically with no real penalty. Dec 08 16:42:13 dorf: agree, lots of room to improve on webui, an updated design doc will help :) Dec 08 16:44:54 rr123: I've been working with ajax lately in another project. If you use it selectively, it's pretty low-footprint. Dec 08 16:45:32 I redid all the "refresh the entire page every x seconds" routines to "refresh this specific div only if something changes". Dec 08 16:46:10 dorf: for CRUD database driven restful backend i would expect ajax will do well, for cgi-jsonrpc backend, some ajax could essentially 'block', or incurs lots of polls, it might not be the best option Dec 08 16:46:57 isn't ajax's goal not to refresh/reload the page from the start Dec 08 16:47:08 sure, no argument there. just open the connections graph with a few thousand connections.. Dec 08 16:47:10 you got a json, and update that div Dec 08 16:47:25 not only will the ajax hang the browser, it'll also take down luci :) Dec 08 16:58:15 rr123: no it is not Dec 08 17:00:35 luci2 was a tech demo to demonstrate the viability of exposing ubus via http Dec 08 17:01:10 that page was updated 2020.09 so i thought it is still relevant, thanks for clarifying Dec 08 17:01:32 that has been backported to luci(1) which is slowly migrating from server-side rendered content to client side rendered views which fetch relevant data via ubus-rpc over http Dec 08 17:01:55 sometime in 2021 I plan to drop the last server side Lua bits Dec 08 17:02:05 at least for the default install Dec 08 17:03:02 an update to the new architecture will be nice, i might be able to help testing or contribute if I can figure out how Dec 08 17:03:11 its all in master Dec 08 17:03:21 and it already is using the new architecture Dec 08 17:03:50 is there a pain free way to update to master without having to reinstall and reconfigure everything? Dec 08 17:04:37 run it in Qemu Dec 08 17:04:55 thats what I do most of the time for development Dec 08 17:05:15 right, so not a good idea on a working router then.. yeah, I've got a vbox install for that. Dec 08 17:05:33 The OpenWrt folding team. https://stats.foldingathome.org/team/268232 Dec 08 17:06:27 i used sshfs mount directly to the board Dec 08 17:06:39 doing that too, but to qemu. not a real board Dec 08 17:08:07 the core js code are all in luci-base/htdoc/luci-static right? Dec 08 17:08:13 yes Dec 08 17:08:19 then each plugin provides its own additional js Dec 08 17:08:37 yes Dec 08 17:10:22 http://openwrt.github.io/luci/jsapi/index.html Dec 08 17:10:30 some classes are undocumented yet, e.g. validation.js Dec 08 17:10:42 will hopefully get around to that eventually Dec 08 17:10:58 is it feasible to add a websocket proxy to uhttpd so for certain pages(e.g. graph) we can use websockets instead of ajax for page update? Dec 08 17:11:10 * karlp giggles Dec 08 17:11:30 there's non non-crappy, non-bloated implementations are available Dec 08 17:11:49 so feasible yes, but the footprint will easily double the entire luci storage footprint Dec 08 17:11:52 weren't you saying that you didn't see any perf improvement of js over lua the other day? now yoiu want to websockets it to skip ajax? Dec 08 17:11:59 or am I mixing you up with someone else? Dec 08 17:12:12 iopsys's owsd and orangerpcd are both new to me, will study their code, seems interesting, but this frontend thing is still very new to me Dec 08 17:13:01 I have been told that the iopsis juci gui does not even compile anymore nowadays because all the nodejs dependencies became incompatible in the meanwhile Dec 08 17:13:11 orangerpcd is a fork of rpcd with Lua scripting support Dec 08 17:13:34 or at least it was, last time I looked at it Dec 08 17:14:07 karlp: it's me, but i'm confused in this field and still learning, will do the ajax way as usual while trying websockets on the side Dec 08 17:14:29 I use mqtt over websockets in for openwrt uis a lot in our stuff, but it depends entirely on what's making the data Dec 08 17:14:37 ajax or websockets don't really hcange that much Dec 08 17:15:45 jow: i think iopsys "abandoned" juci to some extent and use their own stuff for ui now, juci project essentially stopped evolving since 4 years ago Dec 08 17:16:17 rr123: which has been my experience with any "lets make a new luci with modern web technology" over the last twelve years Dec 08 17:16:27 :) Dec 08 17:16:48 people soon get so much entangled in chasing the latest framework that the projects never make it out of the proof-of-concept stage and reach feature parity Dec 08 17:17:12 they usually come with a nice, fancy looking dashboard and some minimal configuration capabilities while not implementing the entire long-tail Dec 08 17:17:36 true, especially on the frontend, which is insane still Dec 08 17:18:04 example: https://github.com/jow-/luci-ng/issues/68 Dec 08 17:18:06 better to focus on a feature-complete solution and evolve it :) Dec 08 17:18:50 (I personally stopped working on LuCI-NG because the Angular framework support devolved faster than I was able to implement the project) Dec 08 17:18:58 tachyons is already out of favor, now it's all tailwindcss and svelte, or whatever Dec 08 17:19:32 lol Dec 08 17:19:37 ne3ver bothered to look at it Dec 08 17:19:39 vanilla css, vanilla js, and you can't go wrong. frameworks are for the lazy :D Dec 08 17:28:59 https://www.peterbe.com/plog/websockets-vs-xhr-2019 Dec 08 17:30:21 In essence, the difference between websockets and ajax is that sockets are push, and ajax is pull, no? Dec 08 17:34:31 dorf: interesting to read but no surprise, latency of course matters, for board like openwrt/luci, most of the time it's local access so certain ajax call will overshadow the latency time Dec 08 17:35:09 yeah, that's my thinking, rr123. mostly access will be over a lan. Dec 08 17:35:54 is it worth the complexity to add websockets to luci, I know too little to say, but will keep playing with the idea as a learning process Dec 08 17:36:12 I'm just wondering if I can transition some of my ajax stuff to websockets without too much hassle. Dec 08 17:36:49 dorf: same here, so far I don't know how to 'secure' the wss calls, i.e. how to authenticate wss Dec 08 17:37:05 well, wss _is_ secure, no? Dec 08 17:37:11 it's encrytped, at least. Dec 08 17:37:21 openwrt needs to get some token for the session and use it on wss, ws has no cross-origin protection either Dec 08 17:38:53 wss is secure as https, but it's different from authentication, e.g. you need logged in to use the wss/ws Dec 08 17:38:54 Sec-WebSocket-Key and Sec-WebSocket-Accept should handle authentication. Dec 08 17:41:30 Does anyone know how to pull a target's triple? (eg: mip64-openwrt-muslabi64) Is there a $() for it? Dec 08 17:43:06 dorf: https://devcenter.heroku.com/articles/websocket-security#authentication-authorization Dec 08 17:44:29 thanks. also: https://blog.stratumsecurity.com/2016/06/13/websockets-auth/ Dec 08 17:44:55 Grommish: gcc -dumpmachine Dec 08 17:45:14 jow: Thank you, sir. Dec 08 17:46:46 https://hackernoon.com/enforcing-a-single-web-socket-connection-per-user-with-node-js-socket-io-and-redis-65f9eb57f66a Dec 08 17:47:15 seems it's doable if you don't mind using some libraries to get the job done, rr123 Dec 08 17:50:05 jow: a quick look at the luci js code, are they ES6 in general? i saw var instead of let/const Dec 08 17:51:29 also no async/await sugars Dec 08 17:51:45 For anyone else looking for what I asked, you can use $(GNU_TARGET_NAME). Thank you again jow! Dec 08 17:52:08 https://makoserver.net/articles/AJAX-over-WebSockets Dec 08 17:52:08 I was looking in ./include instead of the rules.mk where it was kept :) Dec 08 17:52:21 jow: how stable is the current luci in master btw? are there any blockers apart from dsa support? Dec 08 17:52:27 dorf: socket.io must have solved this authentication issue long time ago, the problem is how to do something similar in openwrt, if possible Dec 08 17:52:48 adrianschmutzler: I need your opinion on something, when you get time Dec 08 17:53:13 Grommish: if it doesn't take too long, you can shoot Dec 08 17:53:23 rr123: first you need to persuade jow websockets is a good idea :) Dec 08 17:53:58 dorf: i need learn more to convince myself first :) Dec 08 17:54:14 that too :) Dec 08 17:54:41 adrianschmutzler: Rustlang.. It uses predefine triples for the targets. These are not consistent with the OpenWrt triple convention. Do you recommend 1) morphing the Openwrt triple to match the existing Rustlang triples, or 2) replace the stock rust triples with full custom ones that will match the naming convention Dec 08 17:55:33 adrianschmutzler: example: mips64-unknown-linux-muslabi64 is what rust calls it.. Openwrt's build system calls it mips64-openwrt-linux Dec 08 17:56:24 Grommish: are you trying to get rust into openwrt? I cross-compiled a rust small program and run it on mips-openwrt and it worked fine Dec 08 17:56:26 this is a pendantic, nit picky issue and I'm request you help me figure out the best way to do it :) Not code wise, just overview wise Dec 08 17:56:37 rr123: I've already done it, I just need to finalize the stuff Dec 08 17:56:46 cool Dec 08 17:57:16 One of the issues I'm having is the triple naming convention.. and if I have to change one (and I do for mips64, which is soft-float and dynamically linked) Dec 08 17:57:22 I might as well change them all Dec 08 17:57:24 Grommish: sorry, don't even really understand the question. Dec 08 17:57:45 That touches too much stuff I'm not familiar with Dec 08 17:57:53 adrianschmutzler: Should I make OpenWrt work with stock rust naming conventions, or change rust to match Openwrt's Dec 08 17:58:01 is the gist of the question Dec 08 17:58:15 either way is about the same amount of work and the no user will ever see it Dec 08 17:58:20 it's all internal to the build system Dec 08 17:58:38 but, I figure someoen will have an opinion one way or another on how it should be Dec 08 17:58:46 I don't have any knowledge of rust and this is too far down in the building system for me to judge Dec 08 17:58:47 and I respect your opinion on it Dec 08 17:58:51 also played with golang cross compile, then threw it away, 1. binary size is too big(have not tried shared build which is available) 2. upx compressed go binary will take lots of cpu cycles to decompress 3, this one kills it, a small go binary will ask for like 300MB or 600MB VSS, i know it's not RSS, but still, 600MB VSS on 64MB RAM openwrt is too much for me to continue Dec 08 17:59:01 so I cannot give an opinion, sorry Dec 08 17:59:12 adrianschmutzler: thank you :) Dec 08 17:59:28 rr123: I cross compile fine. I have Suricata6.0.0-beta1 working Dec 08 17:59:56 rr123: Also, I'm not putting rustc/cargo on the device at this time.. it is only for host right now Dec 08 18:00:06 rr123: for cross-compiling Dec 08 18:01:01 but the triples are causing issues, so.. I figured I'd either "fix" them, or scrap them and make new ones as a patch Dec 08 18:01:26 yes cargo on openwrt board(unless it's x86) is going to take hours to build a new release of any rust program Dec 08 18:01:36 No Dec 08 18:01:49 I create an installation binary tarball after the first build Dec 08 18:02:00 how, it took minutes on my 8-core 16GB x86 desktop Dec 08 18:02:09 and call it from Host/InstallDev Dec 08 18:02:18 the FIRST compilation will take a bit, yes Dec 08 18:02:43 After that, unless the package is changed, it'll just use the installation tarball to install the already compiled 9and stored) installation files Dec 08 18:03:18 455079748 Nov 16 05:53 dl/rust-1.49.0-x86_64-unknown-linux-gnu_mips64-unknown-linux-muslabi64sf-install.tar.xz Dec 08 18:03:33 Granted, I am building the ENTIRE 3-stage bootloader and ALL of the tools Dec 08 18:03:56 So the installation tarball is huge, but I will eventually par that down since it includes both the host and the target toolchains Dec 08 18:04:12 looking forward to rust on openwrt :) even though I'm still everything-in-C Dec 08 18:04:41 I am actively looking for people to help test it.. because each triple will need to be mapped one way or the other Dec 08 18:04:58 I've got the rust package and a Suricata6 package to test it with Dec 08 18:05:36 if you get bored enough to try it out, hit me up :) Dec 08 18:05:37 suricata is writting in rust? Dec 08 18:05:49 written Dec 08 18:05:52 rr123: requires rust/cargo as of Suricata5, yes Dec 08 18:06:15 it's the reason I started with rust, because someone wanted suricata Dec 08 18:06:18 *shrug* Dec 08 18:07:02 * rr123 feels the fad is now indeed, re-write everything in rust, i.e. make other code rusty, literally. Dec 08 18:07:15 https://github.com/openwrt/packages/pull/13916/ Dec 08 18:07:36 hehe I'm not a programmer, so rust vs C++ vs whatever doesn't mean much to me Dec 08 18:07:50 but the rust proponents seems to laud it Dec 08 18:08:52 Grommish: btw: I typically don't do packages at all; so, I do not really now the standards that are applied in the packages repo anyway Dec 08 18:09:04 now -> know Dec 08 18:09:36 adrianschmutzler: I know, but you are a reasonable fanatic for common sense standards, so i figured I'd get your opinion on it :) Dec 08 18:10:13 rr123: https://github.com/openwrt/packages/pull/13924 for Suricata6 Dec 08 18:11:01 rr123: ES5 so far, I tried to be very conservative Dec 08 18:11:12 Grommish: but I can't play in every game, so I normally ignore packages repo entirely Dec 08 18:11:15 jow: have you thought about selective refresh with ajax, only updating changed components? looks like currently you're pulling the entire view div? Dec 08 18:11:18 rr123: but some arrow function crept in with a recent PR and IE compat is not a thing anymore anyway Dec 08 18:11:40 adrianschmutzler: Understandable.. :) Thank you, sir! Dec 08 18:11:47 rr123: so yeah, I guess we can start using ES6 goodness Dec 08 18:11:56 spread operators, arrow functions etc. Dec 08 18:12:05 would hold back on async await yet Dec 08 18:12:52 dorf: yes, too complicated for now Dec 08 18:13:05 too much legacy code and logic to support Dec 08 18:14:31 jow: ok. I worked on something similar recently.. selective refresh seems to be a lot less heavy on the cpu. Dec 08 18:14:55 depends on how complex the dirty tracking code is Dec 08 18:17:33 and the transition was a bit fiddly, but I think I now have a decent "recipe" for anything similar. Dec 08 18:17:33 I'm a relative newb when it comes to js, however. No doubt my solution could be accomplished a lot more efficiently :) Dec 08 18:19:57 this code tracks changes in a sidebar that updates regularly: https://gitlab.com/i2pplus/I2P.Plus/-/raw/master/apps/routerconsole/jsp/js/refreshSidebar.js Dec 08 18:21:04 rr123: please please please don't force es6 on us. Dec 08 18:21:04 for a seasoned pro like yourself, that code's probably offensive :| Dec 08 18:21:29 rr123: we're stuck in all sorts of back end environments that cant' rely on tomorrow's browsers. Dec 08 18:22:01 * dorf chuckles Dec 08 18:23:28 well, if jow's going to do it anyway, we can surly survive, just yech. Dec 08 18:24:09 if today's browsers support ES6, what's the problem? :) we're not coding for IE anymore! Dec 08 18:24:32 todays' don't eithter in all places Dec 08 18:24:43 but I mean, I can't stop anyone. Dec 08 18:25:10 the acid test is really "does it support firefox, does it support chrome and derivatives?" no? Dec 08 18:25:44 long gone are the days of having to test for 1/2 dozen different platforms. Dec 08 18:26:02 personasllyu, no, I like not having to get perimssions to install something on some electricians archaic laptop Dec 08 18:26:06 I regualrly run into ie10 Dec 08 18:26:18 but hey, that's me, maybe htat just has to be miy problem Dec 08 18:26:45 however, if you want to go and make things modern and cool, I'd realllllly rather see better support for developers to not have to construct htm on the fly like this sort of cruft: https://github.com/openwrt/luci/blob/master/applications/luci-app-nlbwmon/htdocs/luci-static/resources/view/nlbw/display.js#L331 Dec 08 18:26:45 not accomodating any variant of IE is a feature, not a bug :) Dec 08 18:27:02 and https://github.com/openwrt/luci/blob/master/applications/luci-app-nlbwmon/htdocs/luci-static/resources/view/nlbw/display.js#L612 Dec 08 18:27:35 on that we can agree, but that ship has sailed. Dec 08 18:27:35 99% of the world's browsers doesn't always mean 99% of a given market's users IME, but *shrugs* Dec 08 18:27:44 which ship? Dec 08 18:28:03 the one that uses js to render html. Dec 08 18:28:23 well, can we fix it?! we had a perfectly reasonable html+css, and js for dynamicness Dec 08 18:28:31 why do we now have to throw out html and create it Dec 08 18:28:38 it's hideously hard to work with Dec 08 18:29:17 it is a pain, I agree. Maybe I'm old school, but give me static html and scripts where required any day of the week. Dec 08 18:29:28 it would be my vote for "things to spend modern web dev time on" rather than getting excited about ajax vs serrver sent events vs websockets vs whatever else Dec 08 18:29:42 I use knockout+js templated by lua views a lot traditionally in openwrt Dec 08 18:30:17 the lua view is mostly just tellin luci the thml, and setting some js vars with the media roots, and some url paths Dec 08 18:31:28 yeah, but wasn't lua the problem that ajax is trying to address? Dec 08 18:31:39 not entirely, Dec 08 18:31:53 ltos fo lua views were heavily doing lua scripting _in the view_ before it was rendered to the client Dec 08 18:32:19 if you jhust have luci dispatch the html+js, and provide some url paths to ubus and json-rpc, you still get snappy client stuff Dec 08 18:32:56 in that case, why bother with lua at all? just build the pages in html and add the js where required? Dec 08 18:34:33 and presumably if there's dynamic content that requred reading from ubus, lua can handle that? Dec 08 18:36:05 I guess it's not so different to java/jsp being rendered to html, which is what I'm most familiar with. Dec 08 18:37:47 jsp handles static html (mostly), and java fills in the dynamic content, and javascript provides the icing where required. Dec 08 18:40:14 ES6 is old, heard about ES12? :) Dec 08 18:43:31 openwrt is always taking the bleeding edge anyways(e.g. kernel version), back compatiblity was not the most important thing i feel, so newer js esp ES6 is fine i hope Dec 08 18:56:21 rr123 Dec 08 18:56:21 dorf: If you need to make changes to LUCI that needs more libs installed on the router you are going to get told no pretty quick. Space is a massive thing on inopenwrt Dec 08 18:56:30 on OpenWrt* Dec 08 18:57:18 I am not a dev, but have seen a lot of things shot down because they take up to mutch space! Dec 08 19:07:47 * rr123 feels minified js/css should stay below 500KB, a quick look at /www I have 1.3MB(un-minified), maybe in the future webpack/tree-shaking/whatever can be introduced to produce compact frontend chunks to further reduce the size Dec 08 19:22:49 https://i.imgur.com/SdYPpr0.png Dec 08 19:31:56 Tapper: no intention of using any libraries :) Dec 08 19:32:29 as far as I'm concerned, Tapper, where libraries are concerned, less is more, and none is most :) Dec 08 20:16:57 dorf: they mostly were, but having luci serve the pages automaticallyhandled session logins and urls Dec 08 20:17:58 js can happily talk to ubus via rpcd, there's just no nice templatting in the "js future" at the moment, Dec 08 20:23:58 karlp: template-wise, some cut and paste html components would probably be fine.. luci's not that diverse in terms of the UI. Dec 08 21:08:45 karlp: with ES6 you could use template strings Dec 08 21:08:52 and E() accepts entire HTML fragments Dec 08 21:09:32 so E(`

${greeting}

Dec 08 21:10:00

Even multiline and complex expressions: ${n & 1 ? 'even' : 'odd'}`) Dec 08 21:10:26 (forgot

but yu get the idea Dec 08 21:10:55 that's already looking fugly :) Dec 08 21:11:02 betttter, but still,no editor help with highlighting or completion, it's just yuk Dec 08 21:11:12 still super hard to mock it up without running luci Dec 08 21:11:13 why not? Dec 08 21:11:22 because i'm not competent enough I guess. Dec 08 21:11:23 my editor happily autocompletes ${... } Dec 08 21:11:32 since its a standard ES6 feature Dec 08 21:12:45 I mean, I am _not_ a webdeveloper, I just muddle through and try not to hate it too much. Dec 08 21:13:10 it essentially works like $(...) subshells in double quoted shell strings Dec 08 21:13:51 karlp wants something he can throw into a browser to look up without having to rely on a backend to render it all. :) Dec 08 21:14:00 F12 Dec 08 21:14:06 (I wouldn't complain, either :) Dec 08 21:14:12 enter `foo ${Math.log(10)} bar` Dec 08 21:14:17 observe result Dec 08 21:14:20 no backend required Dec 08 21:14:24 works on about:blank Dec 08 21:15:02 perhaps I should qualify that and say "without a back end or dependence on browser console tools" :) Dec 08 21:15:28 so, like coding C without a compiler? Dec 08 21:15:51 no, more like coding html with a browser :) Dec 08 21:16:20 replace F12 + `foo ${Math.log(10)} bar` with F5 + Dec 08 21:16:29 somehow I am missing the point Dec 08 21:16:46 yeah Dec 08 21:17:05 the point really is generating the templates and table content. Dec 08 21:17:16 Developing templates partials outside the target environment does not really work either Dec 08 21:17:21 doing that statically is a lot easier than doing it via the powers of js. Dec 08 21:17:46 so what is the probkem with doing it statically and copying the resulting markup between `...` ? Dec 08 21:18:18 if you insist on that development workflow you will need to "port" your markup to the actual target env enventually Dec 08 21:18:44 cut your page template into partials, replace stuff with includes, static data with interpolations and so on Dec 08 21:18:58 I'm not insisting on anything, I'm just saying, some workflows are a lot more fluid. I work with whatever's put in front of me, once I get my head around it. Dec 08 21:20:23 However, as a general observation, the current model for generating templates in luci is a barrier to entry that probably puts a bunch of people off contributing.. Dec 08 21:20:56 maybe, but that applies to any sufficiently complex system Dec 08 21:22:51 sure, that's not a bad point, but the question is, is the added complexity actually beneficial? Dec 08 21:23:22 so far you didn't propose any less complex solution Dec 08 21:24:35 the less complex solution would be static html (with templated, cut and paste components) + javascript including ajax to handle the dynamic stuff. Dec 08 21:24:38 I don't have one either, I just suggested that if someone wants to spin wheels, that area might be nicer than just throwing websockets at it :) Dec 08 21:25:01 dorf: that's what luci came from, and it was extrmely complex (and slow) Dec 08 21:25:10 server side rendering on weak MIPS cores is *slow* Dec 08 21:26:17 the current goal is the eventually get rid of any server side interpreter for generating page markup Dec 08 21:26:35 yeah, that's kinda different. Dec 08 21:26:45 there'll be just static HTML, JS and CSS artifacts + an ubus HTTP gateway Dec 08 21:26:50 the server side interpreter is probably where the slow is. Dec 08 21:27:09 (not the rendering of static html) Dec 08 21:27:59 but I actually fial to see the problem. Nothing is stopping you from either using a custom view.htm or from fetch markup via XHR and dropping it into the DOM Dec 08 21:28:01 what you're proposing sounds good, I'd just propose moving the render all the markup via js to pre-formed static html. Dec 08 21:28:25 how to handle things like conditional sections, loops, translation strings? Dec 08 21:28:45 reinvent handlebars.js? Dec 08 21:29:12 jow | there'll be just static HTML, JS and CSS artifacts + an ubus HTTP gateway Dec 08 21:29:15 dynamic stuff handled by javascript. Dec 08 21:29:34 that sounds great to me, but right now, the "static html" seems to be all embedded inside js as well, as fixed constants Dec 08 21:29:43 and that's just where I struggle with the authoring of it. Dec 08 21:29:49 yeah, I like the sound of that. especially the static html part. much easier to work with :) Dec 08 21:29:55 anyone manage to get mDNS (Avahi) and Bonjour browsing working across multiple subnets? Especially two OpenWRT routers connected via IPsec tunnel? Dec 08 21:30:26 philipp64: I can't even get it to work on wireless and wired at the same time with one router :) Dec 08 21:30:37 why is this patch missing in patchwork https://lists.infradead.org/pipermail/openwrt-devel/2020-November/031933.html ? Dec 08 21:30:57 yow. sounds like an IGMP snooping issue? are both wireless and wired in the same bridge group? Dec 08 21:30:59 karlp: but what is preventing you from simply using custom .htm files? Dec 08 21:31:07 that part I don't understand Dec 08 21:31:07 nothing really, it's what I'm mostly doing Dec 08 21:31:39 but it's not how anything else is done, so it feels very left out Dec 08 21:31:58 and when everything has become " a cbi" and that model puts it all in js Dec 08 21:32:20 even though the "CBI" pages are now -much_ more dynamic than just "here's a uci config file presented as a form" Dec 08 21:33:00 it's easier to actually build the DOM from JS than fetching an HTML markup, parsing it into a DOM, locating all elements within it, attach event handlers to it and hope that the structure matches waht the code is expecting Dec 08 21:33:31 otherwise your code will look like the previously linked example: https://gitlab.com/i2pplus/I2P.Plus/-/raw/master/apps/routerconsole/jsp/js/refreshSidebar.js Dec 08 21:33:43 :) Dec 08 21:33:48 endless boilerplate of getElementById() / querySelectorAll() Dec 08 21:34:01 nad hope that noone messes up the selector attributes in the template Dec 08 21:34:16 no doubt that could be improved, but hey, it works, ok :P Dec 08 21:34:47 I didn't mean to imply that the code is bad, just that you'll end up with a lot of additional sync effort Dec 08 21:35:09 that's ok, you made me smile. :) Dec 08 21:35:51 handlebars.js / mustache.js would be an option Dec 08 21:36:03 but then you'll need "the environment" to test and render your markup Dec 08 21:36:11 or any kind of sandbox to provide mock data Dec 08 21:36:37 that code is super inefficient, though.. I've done something similar elsewhere in v2 which just adds a "volatile" class to anything that might require a refresh. much cleaner. Dec 08 21:36:38 and even then you solved the initial rendering problem, not how to handle continuous data updates Dec 08 21:37:48 ynezz: https://patchwork.ozlabs.org/project/openwrt/patch/PS1PR03MB500329AE6D7A3778B9B54166DB100@PS1PR03MB5003.apcprd03.prod.outlook.com/ Dec 08 21:38:08 tmn505: ah, thanks! Dec 08 21:40:41 dangole: hi, you seem to have accepted https://patchwork.ozlabs.org/project/openwrt/patch/PS1PR03MB500329AE6D7A3778B9B54166DB100@PS1PR03MB5003.apcprd03.prod.outlook.com/ Dec 08 21:40:56 dangole: do you plan to push it eventually sometime soon? Dec 08 21:41:16 just seeing that issue with the valgrind Dec 08 21:42:07 ynezz: was test-driving it in the past couple of days, works fine, i'll push it now Dec 08 21:42:17 does it compile as it is? Dec 08 21:42:53 ustream-io-openssl.c:45:17: error: invalid use of incomplete typedef ‘BIO’ {aka ‘struct bio_st’} Dec 08 21:43:11 ah, that's maybe due to my -Wextra Dec 08 21:43:37 but still something fishy about that Dec 08 21:45:52 karlp: interesting discovery! (1) Avahi wants IFF_MULTICAST set, even on IPsec (XFRM) tunnel interfaces, (2) avahi-daemon.conf uses the first value it sees in the config, not the last, so you can’t have “[reflector] \n enable-reflector=no \n enable-reflector=yes \n” because only the first one gets set (cleared, really) so it needs to be fully commented out, (3) you need to turn off IPv6 if you’re not using it and (4) turn on Dec 08 21:45:53 “allow-point-to-point=yes”… Dec 08 21:46:12 as we speak, I’m synching my iPhone to a Mac mini 9 miles away… Dec 08 21:46:29 jow: continuous updates are easy enough in that context. selective ajax refresh or websockets. whatever works with the least overhead. Dec 08 21:47:39 you can't have a few dozen independent components on the page each do their own ajax calls Dec 08 21:48:04 it needs to be centrally managed, also to avoid double fetching the same data Dec 08 21:48:12 you have one ajax refresh that runs and checks for changed content. Dec 08 21:48:37 which needs a generic mechanism to tie markup nodes to data Dec 08 21:48:55 see the updateVolatile function on https://gitlab.com/i2pplus/I2P.Plus/-/raw/master/apps/i2psnark/resources/js/refreshTorrents.js .. that's v2 of my ajax refresh stuff. Dec 08 21:48:57 or you end up writing endless amounts of template specific glue and match code Dec 08 21:49:44 yeah, the generic mechanism is just to tag anything that may require a refresh with a "volatile" class tag Dec 08 21:50:08 and a selector into the view model data Dec 08 21:50:10 and then iterate through those when you refresh to see what's changed. Dec 08 21:50:16 and you need to introduce sequences Dec 08 21:50:30 fir things like lists of data Dec 08 21:50:33 philipp64: hrm, I'm only using umdnsd now, as it's better integrated in procd, and it worked enough for me.. Dec 08 21:51:48 let me know if you get that working… Dec 08 21:52:46 you could do ... or
  • ...
etc. Dec 08 21:52:52 that would be the angular approach Dec 08 21:52:57 then you need dirty tracking Dec 08 21:53:45 this is the point where I defer, my js isn't that hot. :) Dec 08 21:54:25 it's simple on paper but the details aren't. Otherwise Angular would've been a ~200 line JS file Dec 08 21:57:24 anyhow, will think a bit about it. Off to be for now Dec 08 21:57:49 have fun being o/ Dec 08 22:19:12 ynezz: you were right, it doesn't actually compile. I was testing it with mbedtls by accident and never actually compiled the openssl part before. Dec 08 22:19:47 ynezz: and the fix is non-trivial... Dec 09 00:10:02 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 97.6% packages reproducible in our current test framework.) Dec 09 01:29:32 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.4.82&id=72dbcf72156641fde4d8ea401e977341bfd35a05 Dec 09 01:29:35 sad Dec 09 01:31:19 oh they never fixed getrandom. thought they did Dec 09 01:33:15 oh it seems they did https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.4.82&id=50ee7529ec4500c88f8664560770a7a1b65db72b Dec 09 01:33:28 I wonder if the util-linux patch can be removed then. **** ENDING LOGGING AT Wed Dec 09 02:59:56 2020