**** BEGIN LOGGING AT Mon May 10 02:59:56 2021 May 10 06:46:14 Hauke: ping Jow about that luci-theme-openwrt-2020 May 10 08:38:20 that discussion was a few days ago and there was no result, though May 10 10:47:36 I thought it was positive, but that one or two niggles were reported, and jow was going to look at addressing them first? May 10 10:54:20 i don't know, I didn't follow May 10 10:54:30 i think we should handle DSA first though May 10 11:32:05 jow: should we change the default luci theme to luci-theme-openwrt-2020 for 21.02? May 10 11:36:30 Hauke: it should definitely receive some testing in master first May 10 11:36:37 yes May 10 11:37:46 Hauke: did you have a look at my bootstrap mods? (wip) May 10 11:37:55 I hear rumours of dsl issues on xrx200 lantiq and 21.02, alas I myself not in a good position to test 21.02RC on important link..... May 10 11:38:57 Also I'm not really sure about reliability of 21.02rc1 on xrr200 with wifi/ath10k ct firmware .... at least one with this build is rebooting itself! May 10 11:48:39 Hauke: honestly it's a step back in usability, that theme May 10 11:51:03 outstanding issues can be fixed, if there's demand.. running fine on my 19.0x install -> https://github.com/openwrt/luci/pull/4617 May 10 11:52:02 ideally the js wouldn't be relied on for rendering all the html, and would be used a bit more sparingly. as it is, theme development is an absolute pain. May 10 12:20:33 Hauke: oh and on forum I see request for 2 other themes: https://forum.openwrt.org/t/openwrt-21-02-0-first-release-candidate/95039/158?u=rmilecki May 10 12:21:02 there is no way a complete theme switch like that is going to make everyone happy May 10 12:21:11 can we possible tweak existing theme instead? May 10 12:21:15 *possibly May 10 12:22:47 rmilecki: that's what I was doing with bootstrap. May 10 12:25:45 i thought bootstrap was cool before we got CSS grids and flex May 10 12:26:06 bootstrap was never cool :) May 10 12:26:29 it's just a huge waste of screen estate. May 10 12:27:00 i really don't know how to handle that, everyone has its own idea for a theme :P May 10 12:28:58 i was hoping that for small things (changes) we can discuss & agree on what is better May 10 12:29:20 but most people seem to prefer develop sth from a scratch May 10 12:29:29 instead of working on existing solution (theme) May 10 12:30:05 rmilecki: if you include themes people will expect support for them as well May 10 12:31:13 i think that's something jow highlighted before. People contribute a theme, it looks very nice, everyone is excited, then the OpenWrt codebase gets changes which breaks custom themes, but the authors have moved on or don't care anymore May 10 12:31:43 true May 10 12:32:19 code rot is quickly visible in the web UI unfortunately May 10 12:46:42 I think I made it clear previously, I don't mind maintaining a theme if it's going to be used, but I'd REALLY like to see some movement towards some static html as a basis for the UI, everything done with js is just nasty. May 10 12:51:51 And instead of starting from scratch I took the default theme and tried to evolve it rather than making super brash changes. May 10 12:53:20 I don't mind either way, if the project wants something else, no worries. Like I said, I'm happy just running it on my instance. May 10 12:54:20 dorf_: my observations were general, they weren't directed at what you said or your work. May 10 13:01:18 * dorf_ nods and smiles May 10 13:09:05 Hauke: don't switch May 10 13:18:03 jow: is there anything you find incorrect / broken / confusing in list of device type bridge options? May 10 13:18:40 jow: i mean all those ifname / stp / forward_delay / priority / ageing_time / hello_time (...) / mtu / mtu6 / macaddr / txqueuelen / enabled ( ...) May 10 13:19:40 mtu and mtu6 are IPv4 and IPv6 specific, they shouldn't be a bridge device property May 10 13:20:13 ifname is complicated... does it refer to the name of the bridge or to the names of the bridge ports? May 10 13:20:36 i found it misleading too May 10 13:20:50 jow: what option name should we have instead? May 10 13:21:05 list ports May 10 13:21:38 jow: do you see any other common options that don't belong to bridge? https://lxr.openwrt.org/source/netifd/device.c#L31 May 10 13:21:49 jow: except for mtu and mtu6? May 10 13:22:35 ip6segmentrouting, rpfilter May 10 13:22:47 acceptlocal (?) May 10 13:23:19 acceptlocal is an IPv4 property as well May 10 13:26:06 thanks May 10 13:36:24 that's another conceptual issue May 10 13:36:44 right now, config device sections are used for two purposes (and config interface sections for three purposes): May 10 13:36:54 1) specifying layer 3 IP settings May 10 13:37:01 2) declaring interfaces May 10 13:37:28 interfaces as in Linux netdevs and declaring as in triggering the creation (or capturing existing ones) May 10 13:37:31 3) May 10 13:37:36 serving as sysctl containers May 10 13:37:58 config device w/ type bridge mixes 2 & 3 May 10 13:38:15 config device section allows specifying IP address?! May 10 13:39:20 do you mean something like May 10 13:39:23 config device May 10 13:39:25 option type 'bridge' May 10 13:39:26 option name 'test' May 10 13:39:28 option ipaddr '192.168.1.1' May 10 13:39:29 ?? is that going to work? May 10 13:42:19 jow: what's wrong with mixing 2 & 3 ? as long as it affects layer 2 device May 10 13:42:40 rmilecki: sec, phone May 10 13:42:42 gimme 10m May 10 13:42:44 sure May 10 13:47:58 jow: [my understanding] i though that config device type bridge is UCI section that should contain label 2 options (interface name, list of ports, some bridge sysctl setup) May 10 14:00:02 rmilecki: config interface xxx; option type bridge "inherits" config device; option type bridge settings May 10 14:00:19 rmilecki: but just an arbitrary subset, and even that collides with protocol specific options in some cases May 10 14:00:25 config interface + type bridge is a mess; ) May 10 14:00:34 yeah, it should be removed for good May 10 14:00:50 as for mixing sysctls + device declaration properties May 10 14:00:54 i'm going to remov ethat May 10 14:01:05 (remove interface type bridge) May 10 14:01:12 I am not 100% sure whether these are intersection free May 10 14:02:13 but it is probably fine May 10 14:02:36 as long as any "config device" type supports the same subset of device type agnostic sysctls May 10 14:03:01 what would be cleaner from my pov would be splitting "declarations" and "configurations" of devices May 10 14:03:23 that means reserve "config device" for layer 2 related netdev sysctls and ethtool settings May 10 14:03:33 and introduce new section types for device declarations May 10 14:03:50 that is, config bridge instead of config device; option type bridge May 10 14:04:45 jow: ok, i got the idea May 10 14:05:00 or config vlan instead of config device; option type vlan May 10 14:05:01 i'm not sure if we need that split of sysctls May 10 14:05:19 probably not as long as it is consistent May 10 14:05:22 i'm going to trust your opinion on that May 10 14:05:56 jow: so what, can we keep sysctl & device layer 2 options in the same section? May 10 14:06:31 jow: i'm not sure if i'm right, but it seems like an API choice May 10 14:06:52 jow: some things can be set by sysctl, some by netmsg (like addbr) May 10 14:08:01 jow: i've to go now for a bit, for now I'm planning to keep layer 2 options & sysctls in one UCI section, let me know if you think it's a bad idea after all for some reason May 10 14:09:52 I guess it is fine, maybe you could start an etherpad or something where a mockup could be scribbled together May 10 19:02:19 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 98.0% packages reproducible in our current test framework.) **** ENDING LOGGING AT Tue May 11 02:59:57 2021