**** BEGIN LOGGING AT Tue May 18 02:59:56 2021
May 18 04:25:40 <philipp64> Tapper: that's probably from the makefiles that don't support parallel builds.
May 18 07:05:18 <philipp64> rsalvaterra: ping...
May 18 07:05:43 <philipp64> actually, if you could have a look at PR #4184 that would be awesome...
May 18 07:06:16 <philipp64> ldir: or you...
May 18 07:07:52 <philipp64> Too bad there's no easy way to request reviewers on openwrt/openwrt ...
May 18 08:02:36 <rmilecki> jow: i've realized we're going to use "ports" UCI option for both types of sections: "device" (type bridge) and "bridge-vlan"
May 18 08:02:49 <rmilecki> jow: i don't think it's a big deal, unless you have different opinion?
May 18 08:03:22 <rmilecki> grepping sources may be a bit less easy, but I don't find it a strong argument
May 18 10:09:56 <blogic> https://pastebin.com/Km4MnmMp
May 18 10:10:12 <blogic> got wired ieee8021x working on DSA switches :-D
May 18 10:10:28 <stintel> neat
May 18 10:10:35 <stintel> very neat
May 18 10:10:40 <blogic> yup
May 18 10:11:02 <blogic> the daemon needs a little more love, the had config currently expetcs a local eap_user file to be present
May 18 10:11:16 <blogic> will extend that a bit, s.T. you can define a radius server in UCI
May 18 10:11:25 <blogic> and I would like local EAP-TLS to work aswell
May 18 10:11:41 <stintel> soon I will have to add moar complexity to my network :D
May 18 10:11:58 <blogic> https://github.com/blogic/ieee8021x/
May 18 12:20:53 <rmilecki> what the heck
May 18 12:20:56 <rmilecki> build_dir/target-aarch64_cortex-a53_musl/netifd-2021-05-18-7277764b/interface.c:259:3: error: 'fallthrough' undeclared (first use in this function)
May 18 12:20:58 <rmilecki>    fallthrough;
May 18 12:20:59 <rmilecki>    ^~~~~~~~~~~
May 18 12:21:22 <rmilecki> nbd: ??
May 18 12:22:59 <nbd> did you update libubox?
May 18 12:23:32 <nbd> the libubox update that i pushed adds the fallthrough macro
May 18 12:24:10 <karlp> why is that better than the documented comment form?
May 18 12:24:37 <rmilecki> nbd: ah, ok, i was trying to bump netifd locally without your recent ubox change
May 18 12:24:45 <karlp> mentioning the changed requirements in the commit message would hav ebeen nice :)
May 18 12:24:48 <nbd> karlp: clang doesn't accept the comment form
May 18 12:25:37 <karlp> does gcc accept the attribute?
May 18 12:25:53 <nbd> i copied the macro from the kernel
May 18 12:25:59 <karlp> seems rough to me to puyt this in an external dep, but hey, just the peanut gallery....
May 18 12:26:00 <nbd> so it's a form that is accepted by both clang and gcc
May 18 12:27:45 <nbd> what do you mean by 'external dep'? netifd already depends on libubox and uses a lot of utility functions from it
May 18 12:27:50 <rmilecki> nbd: compiles fine, thanks!
May 18 12:28:30 <nbd> karlp: and if you update openwrt without having specific versions of netifd or libubox locked in via git-src, there is no compile error
May 18 12:35:20 <karlp> but you don't have any reference to which libubox is required at any point, there's no submodule, it's just "update all of them and hope they currently sync"
May 18 12:35:46 <karlp> but really, not my playground, sorry for interfering
May 18 12:36:57 <nbd> they're not widely used outside of openwrt
May 18 12:37:04 <nbd> and if you update openwrt, you get them updated in the right order
May 18 12:37:20 <nbd> don't worry about interfering, i just want to understand your concerns
May 18 12:53:37 <rmilecki> karlp: it's the same store when we extend some API in ubox and then use it in another OpenWrt software
May 18 12:53:47 <rmilecki> karlp: that requires bumping in the correct order
May 18 12:53:51 <rmilecki> nothing new here
May 18 12:53:57 <rmilecki> *story
May 18 12:58:49 <rmilecki> can someone try /etc/init.d/network restart
May 18 12:59:02 <rmilecki> can you access your router after that?
May 18 12:59:09 <rmilecki> a simple ping will do
May 18 13:00:40 <nbd> works for me
May 18 13:30:45 <rsalvaterra> blogic: Is it possible to learn this power? :)
May 18 13:32:17 <rsalvaterra> blogic: Oh, nevermind, I just saw your repository now.
May 18 13:34:28 <rsalvaterra> aparcar[m]: I'm updating ELFKickers here, but sstrip is unchanged, it seems. Is it worth the bump? It's trivial enough, though…
May 18 13:51:45 <jow> rmilecki: I guess having "ports" for both is fine
May 18 13:51:51 <rmilecki> jow: ok, th
May 18 13:51:52 <rmilecki> x
May 18 13:51:55 <jow> rmilecki: I also like the ifname->device change
May 18 13:52:00 <rmilecki> cool
May 18 13:52:05 <rmilecki> it also matches bridge-vlan section option
May 18 13:53:04 <jow> rmilecki: as for disabling support for legacy bridge creation in luci... I was considering a forced config migration similar to how it is done for wireless
May 18 13:53:28 <jow> rmilecki: to see what I mean, remove the name from any "config wifi-iface" in your /e/c/wireless and open the wifi config page in luci
May 18 13:53:39 <rmilecki> jow: i pushed that one an hour ago, i decided to wait with the other patch till tomorrow
May 18 13:53:46 <jow> rmilecki: would love to see something like that to migrate type bridge to device bridge
May 18 13:54:21 <rmilecki> let me check in LuCI what do you mean
May 18 13:54:23 <jow> then we can simply drop all legacy code
May 18 13:54:56 <rmilecki> i need a second to switch to some wireless router
May 18 13:59:51 >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.)
May 18 14:01:13 <aparcar[m]> rsalvaterra: don't
May 18 14:01:54 <rsalvaterra> aparcar[m]: Sure.
May 18 14:17:38 <rmilecki> jow: ok, i saw that warning in LuCI
May 18 14:18:39 <rmilecki> jow: i guess it did some "uci set wireless.@wifi-iface[1]=wifinet0" for me
May 18 14:18:44 <jow> right
May 18 14:19:21 <rmilecki> jow: i still don't know when & why we should need that for network?
May 18 14:19:32 <Hauke> nbd: ok, I will wait till the mac80211 patches show up in 4.19 stable branch
May 18 14:20:01 <rmilecki> jow: also what about users that don't want/use LuCI?
May 18 14:20:12 <rmilecki> migration should not be handled by LuCI
May 18 14:23:35 <aparcar[m]> rsalvaterra: I mean, don't bother. Let's wait and see if the package is put into it's own repo and then we can change things around
May 18 14:24:50 <aparcar[m]> rmilecki: can you give me a tl;dr of the "ports" vs "ifname" changes? I'm assuming there is more to it than renaming the variable
May 18 14:25:06 <rmilecki> aparcar[m]: i'll link you to examples I think
May 18 14:25:18 <aparcar[m]> rmilecki: thanks!
May 18 14:25:53 <rmilecki> aparcar[m]: board.json minor change: https://patchwork.ozlabs.org/project/openwrt/patch/20210514092147.30666-1-zajec5@gmail.com/
May 18 14:26:14 <rmilecki> aparcar[m]: old -> new syntax example: https://patchwork.ozlabs.org/project/openwrt/patch/20210515191240.29676-1-zajec5@gmail.com/
May 18 14:26:45 <rmilecki> aparcar[m]: proposed change for ifname -> device: https://patchwork.ozlabs.org/project/openwrt/patch/20210517144925.4913-1-zajec5@gmail.com/
May 18 14:26:53 <rmilecki> aparcar[m]: check commit messages in above for examples
May 18 14:27:23 <rmilecki> aparcar[m]: so it's basically rename + using "section device" for bridge
May 18 14:29:32 <jow> rmilecki: I don't care about cli users :)
May 18 14:29:42 <jow> I mean not in a sense thatthey need any handholding
May 18 14:29:52 <rmilecki> rmilecki: well, if we do it "my way", it's going to handle CLI usera AND LuCI users
May 18 14:30:14 <jow> I don't want to maintain redundant code paths to let cli users clinge to their deprecated configs
May 18 14:30:28 <aparcar[m]> jow: how big is ucode if you compile it with all regular features?
May 18 14:30:37 <rmilecki> jow: no worries, i'm planning to drop legacy code from netifd afterwars
May 18 14:30:39 <jow> either hey want to use luci, they they'll get force migrated so that they can configure using luci
May 18 14:30:46 <rmilecki> jow: so the only thing we're going to stay with it 1 uci-defaults file
May 18 14:30:56 <jow> or not, in this case the luci network config won't work to not break legacy configs
May 18 14:31:28 <rmilecki> jow: no, let's don't migrate just LuCI users
May 18 14:31:37 <rmilecki> jow: really, that's the benefit from that?
May 18 14:31:43 <rmilecki> let me just "migrate" everyone
May 18 14:31:54 <jow> I was referring to your proposed patch
May 18 14:31:58 <aparcar[m]> rmilecki: thanks for the sources
May 18 14:32:01 <rmilecki> jow: which one? ;)
May 18 14:32:12 <jow> there you disabled the ability to create old style bridges but left the code to configure them in place
May 18 14:32:20 <jow> also uci-defaults is unreliable
May 18 14:32:27 <rmilecki> why is it unrel?
May 18 14:32:31 <jow> factory reset to old configs on self built images, restore from old backups
May 18 14:32:42 <jow> sysupgrade retaining old configs
May 18 14:33:05 <jow> users copy-pasting examples fro mthe web after your migration ran
May 18 14:33:07 <rmilecki> uci-defaults run after sysupgrade
May 18 14:33:24 <jow> scp'ing configs from one device to another
May 18 14:33:28 <rmilecki> restore config -> ok, that will fail
May 18 14:34:06 <rmilecki> jow: i could leave uci-defaults with "exit 1" to hack that around
May 18 14:34:12 <rmilecki> i'm not sure how much you like it
May 18 14:36:04 <rmilecki> jow: i don't have any good idea for users restoring (restore / scp / whatever) configs using old syntax except having that uci-defaults migration script with "exit 1" so it runs on every boot
May 18 14:36:21 <jow> rmilecki: I've no objection against you adding a uci-defaults script
May 18 14:36:30 <rmilecki> jow: ok
May 18 14:36:39 <rmilecki> jow: let me look at it now then
May 18 14:36:51 <jow> the LuCI solution is just another, more reliable mechanism for those that do use luci to edit the config
May 18 14:36:56 <rmilecki> jow: i'm also working on uTutorial on DSA & UCI & LuCI
May 18 14:36:59 <rmilecki> i'll post on forum
May 18 14:37:07 <jow> because for those, the config will be migrated at the very point in time they're trying to change it
May 18 14:37:22 <jow> [in case it isn't already migrated]
May 18 14:37:31 <jow> [for wahtever reason]
May 18 14:38:40 <jow> the other advantage of the gui approach is that you actually trigger it yourself (by visting the settings page) and thet you initiate the migration explicitely (by pressing proceed)
May 18 14:39:08 <jow> vs. a uci-defaults script that changes a network config without the user consenting
May 18 14:39:33 <jow> also keep in mind that automatic uci operations on a file changes its indentation and that all comments will be stripped
May 18 14:39:46 <jow> to a cli user that is likely a far bigger deal than to a gui one
May 18 14:40:29 <rmilecki> can you ever make everyone happy when doing such changes? ;)
May 18 14:41:12 <jow> no, I just explained the reasoning for wanting a ui assisted migration (in addition). Because it allows me to simplify the code there without having to care about whatever core ends up doing
May 18 14:41:59 <nbd> i strongly prefer only doing the migration for luci users at the moment (in the way that jow proposed)
May 18 14:43:38 <jow> for core we should start with *shipping* updated defaults, migration can be (re)considered much later
May 18 14:43:58 <nbd> right
May 18 14:44:15 <nbd> there is very little (if any) benefit to early forced migration for cli users
May 18 14:44:39 <nbd> but a non-neglegible risk of breaking working configs
May 18 14:44:43 <aparcar[m]> zorun: please review my AUTORELEASE busybox patch if you have the time :)
May 18 14:45:58 <rmilecki> blah
May 18 14:46:11 <rmilecki> ok, i'll see to LuCI to add similar workaround to wifi-iface one
May 18 14:46:43 <aparcar[m]> openwrt has a cli?
May 18 14:49:16 <jow> aparcar[m]: on x86/64 its ~74K after sstrip & gzip for all modules and the interpreter itself
May 18 14:49:41 <jow> aparcar[m]: it'll likely become smaller when disabling the trace support
May 18 14:52:28 <aparcar[m]> jow: thanks!
May 18 15:05:57 <aparcar[m]> rmilecki: thanks for the examples, looks good to me. I'm still missing the big picture why this is terrible difficult to implement into a UI and needs the change but I'm sure it makes sense :)
May 18 15:07:46 <aparcar[m]> lynxis: is there a missunderstanding on https://github.com/openwrt/openwrt/pull/4170 (busybox timestamps)? I'd merge this since based on rsalvaterra experience busybox seems to be rather "slow" to respond
May 18 15:08:58 <rsalvaterra> aparcar[m]: I'd merge it for the time being, yes. My BusyBox patch took months to be merged, IIRC.
May 18 15:11:42 <aparcar[m]> I'll wait for lynxis and then merge it
May 18 15:22:12 <aparcar[m]> does OpenWrt 19.07 support JavaScript based LuCI apps?
May 18 17:19:26 <zorun> aparcar[m]: I don't know what AUTORELEASE is
May 18 17:29:20 <jow> aparcar[m]: yes, it does
May 18 17:47:41 <aparcar[m]> jow: thanks. could you please help me with some comments on the current luci-app-attenddsysupgrade? I didn't really understand all the smart LuCI JS concepts
May 18 17:49:04 <aparcar[m]> zorun: nevermind then ;)
May 18 18:09:43 <aparcar[m]> jow: I'm thinking about backporting the latest luci-app-attendedsysupgrade to 19.07 but I think the menu.d acl attribute isn't supported, however used by the app (see https://github.com/openwrt/luci/blob/60696d4d4901a53a1f97d8e76ebff849c6a22e78/applications/luci-app-attendedsysupgrade/root/usr/share/luci/menu.d/luci-app-attendedsysupgrade.json#L9). Do you have a suggestion?
May 18 18:35:43 <rmilecki> jow: how can I save all uci changes without uci.save() which brings a popup with summary?
May 18 18:36:24 <rmilecki> jow: i added migration code that does all required uci.set() calls and then return uci.save().then(L.bind(L.ui.changes.init, L.ui.changes)).then(L.bind(L.ui.changes.displayChanges, L.ui.changes));
May 18 18:36:29 <rmilecki> but that brings a popup
May 18 18:37:21 <rmilecki> jow: i checked uci.save function and it does all kind of magic related to the .callAdd() and .callSet(), I don't want to reimplement that magic
May 18 18:38:23 <rmilecki> jow: or should I avoid uci.set() calls and use .callSet() directly?
May 18 18:49:06 <blogic> rmilecki: on a rampage, love it :-)
May 18 18:52:02 <rmilecki> uh, i hit something fishy
May 18 18:52:04 <rmilecki> RPCError: RPC call to uci/set failed with ubus code 2: Invalid argument
May 18 18:52:09 <rmilecki> at handleCallReply (http://192.168.1.1/luci-static/resources/rpc.js?v=git-21.124.24916-0faf9a4:94:7)
May 18 18:52:34 <rmilecki> but reply in Network looks actually cool to me :| [{"jsonrpc":"2.0","id":23,"result":[0,{"section":"cfg0a0f15"}]},{"jsonrpc":"2.0","id":24,"result":[2]}]
May 18 18:52:43 <rmilecki> oh, the second one does not
May 18 18:58:59 <rmilecki> ok, fixed it :)
May 18 18:59:06 <rmilecki> foo: null < bad
May 18 18:59:10 <rmilecki> foo: '' < fine
May 18 19:13:40 <rmilecki>  /etc/config/network refactoring stage 1 completed
May 18 19:39:18 <Tapper> rmilecki +1000 XP +1 constitution IP
May 18 19:54:58 <blogic> Tapper: he is really is a gem ;)
May 18 20:00:37 <rmilecki> ;)
May 18 20:01:02 <rmilecki> let's see how many bug reports we get now ;)
May 18 20:01:12 <stintel> =)
May 18 23:25:20 <aparcar[m]> anyone knows how many devices hit openwrt.pool.ntp.org a day?
May 19 00:05:46 <aparcar[m]> rsalvaterra: ping
May 19 00:09:29 <rsalvaterra> aparcar[m]: pong, what's up?
May 19 00:10:01 <rsalvaterra> That's a good question. Is the pool overloaded?
May 19 00:10:09 <aparcar[m]> I just build this and busybox shrinks by a kb, which is somewhat against my assumption https://github.com/openwrt/openwrt/pull/4156
May 19 00:12:54 <rsalvaterra> aparcar[m]: I may be wrong, but I have this faint idea the BusyBox nslookup wouldn't allow to specify the DNS port.
May 19 00:13:18 <aparcar[m]> tell me more
May 19 00:14:10 <rsalvaterra> I can't, I'd have to rebuild and test myself. Or look at the source. Either way, it's past midnight here, and I need to hit the sheets. :)
May 19 00:14:31 <aparcar[m]> bueno
May 19 00:15:13 <rsalvaterra> I'll take a look at it in the morning, if not overwhelmed at $dayjob.
May 19 00:15:33 <aparcar[m]> I'll look more into it and see if I can figure something out :)
May 19 00:16:22 <aparcar[m]> Change 	Local	Remote 	Package
May 19 00:16:22 <aparcar[m]> -1204	230492	231696	busybox
May 19 00:16:34 <rsalvaterra> Alright, tell me if you get there before me, so we don't duplicate efforts.
May 19 00:16:44 <aparcar[m]> you'll see in the commit log ;P
May 19 00:16:47 <rsalvaterra> That's a nice diff, indeed!
May 19 00:17:19 <aparcar[m]> well these 1200 bytes may contain some port functionality
May 19 00:18:08 <rsalvaterra> Yeah, quite a difference. Enough for a lot more going on.
May 19 00:18:24 <rsalvaterra> Alright, bed time. Cheers, guys! :)
May 19 00:18:51 <aparcar[m]> bye
May 19 01:32:40 <wingsorc> When I try to boot my custom initramfs kernel I get the error : "Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 543"  in u-boot. I searched the internet for this error and it seem its a buggy/limited lzma implementation in the u-boot version. Is there a generic workaround for this? I saw some references to changing the paramters fed to lzma but these options don't apply for the current codebase
May 19 01:34:11 <wingsorc> by booting I mean I load the image into ram with tftpboot and run bootm in u-boot
May 19 01:42:28 <wingsorc> ok I got it I just needed to load the image to a higher address
May 19 02:27:35 <owrt-snap-builds> Build [#106](https://buildbot.openwrt.org/master/images/#builders/61/builds/106) of `arc770/generic` failed.
May 19 02:53:09 <wingsorc> where can i get the configuration used for building stable release (i.e. with luci and other goodies)?
**** ENDING LOGGING AT Wed May 19 02:59:57 2021