**** BEGIN LOGGING AT Wed Jul 24 02:59:57 2019 Jul 24 04:46:30 has lach1012 been around lately? Jul 24 04:51:43 nope, Christian is usually active during the weekend Jul 24 04:51:57 probably enjoying holidays as well Jul 24 04:58:38 i wanted to ask about commit 4b280ad9 Jul 24 05:11:57 seems like blocktrron has co-authored it, and he could be reached here Jul 24 05:14:37 the commit message attributes the target/linux/ipq40xx/patches-4.14/997-device_tree_cmdline.patch file to lach1012 Jul 24 05:15:34 blocktrron may not have been aware that lach1012 simply moved that file from target/linux/generic Jul 24 05:15:53 i know this because i wrote it originally Jul 24 05:16:03 then you've probably better luck trying to reach him over email Jul 24 05:16:49 but i wrote it wrong, back then Jul 24 05:18:10 rmilecki: /bin/sh: 1: openwrt/staging_dir/hostpkg/bin/lua: not found Jul 24 05:18:26 i think it should be corrected and moved back to target/linux/generic Jul 24 05:18:32 thoughts? Jul 24 05:18:45 rmilecki: I was saying that, didn't I? :-) Jul 24 05:18:47 ynezz: that's hard to comment on Jul 24 05:19:05 ynezz: what are you doing? what is executing that? Jul 24 05:19:17 downstream project, Gluon Jul 24 05:19:46 can't we simply make lua -> lua5.1 by default (as it was before)? Jul 24 05:20:13 i don't think i changed that Jul 24 05:20:15 did i? Jul 24 05:20:42 you still didn't tell me what are you doing and where does that error appear Jul 24 05:20:47 is that at compilation time of gluon? Jul 24 05:21:00 AFAIR it was working fine a month ago, I've just tried to rebuild Jul 24 05:22:00 it's not a big deal, just wondering is it has to be fixed in Gluon or we're able to make it somehow working Jul 24 05:22:11 or it's necessary breakage in order to support other Lua versions Jul 24 05:23:19 ok, I think the problem is that we use symlink for target files only Jul 24 05:23:24 we don't use symlink for staging_dir Jul 24 05:23:33 scripts/site.sh:exec openwrt/staging_dir/hostpkg/bin/lua -e "print(assert(dofile('scripts/site_config.lua').$1))" 2>/dev/null Jul 24 05:24:23 OK, that helps Jul 24 05:24:40 we can fix gluon to call staging_dir/hostpkg/bin/lua5.1 Jul 24 05:24:45 yes, indeed Jul 24 05:24:54 or we can also have "lua" package provide a symlink lua -> lua5.1 Jul 24 05:25:02 just like we do for target Jul 24 06:27:12 DonkeyHotei: well, it should be first upstreamed (or adjust to upstreamable version), then moved into generic/backports Jul 24 06:29:00 rmilecki: thanks a lot for such quick fix! :) Jul 24 06:29:12 sure Jul 24 06:29:29 jow: does it look good to you? [PATCH] lua: create "lua" symlink in staging dir Jul 24 06:29:38 i don't want to do anything stupid Jul 24 06:30:16 it looks good to me Jul 24 06:32:42 maybe it would make sense to add symlink for luac5.1 as well (just bikeshedding here) Jul 24 06:49:52 DonkeyHotei: what do you mean with "wrote it wrong"? Jul 24 06:50:38 We could also try to unify the bootargs-append and bootargs-override hacks and move one over to generic. Jul 24 06:53:38 rmilecki: confirmed, problem solved with your patch Jul 24 10:31:05 Help please. Have a process under procd control. At system boot the process fails to work correctly because networking isn't up sufficiently yet. The process has an internal 2 minute retry period, so wait 2 minutes and all is good. Jul 24 10:31:45 it would seems reasonable to set up an interface trigger to poke the process on relevant interface state change Jul 24 10:34:47 My problem is how to define the reload_service() Jul 24 10:36:26 The documentation says "procd_send_signal servicename" but I may have multiple instances of the service and I may not want to signal all of them. Jul 24 10:52:06 ldir: procd_send_signal(service, [instance], [signal]) Jul 24 10:52:23 where do I get the instance from ? Jul 24 10:53:08 its either explicitely named, when passed as argument to procd_open_instance Jul 24 10:53:20 or its autogenerated, starting with instance1, then counted up Jul 24 10:53:25 see ubus call service list Jul 24 10:54:10 with dnsmasq for example the instances are named after the corresponding uci sections Jul 24 10:56:14 ok, I fundamentally don't understand (anything!), so procd sees an interface change 'event' and then because it matches an interface up trigger, must call /etc/init.d/https_dns_proxy reload Jul 24 10:56:51 in /etc/init.d/https_dns_proxy we must land in reload_service() Jul 24 10:57:40 and I'm wondering what context info I have when I've been kicked by procd in this way. Jul 24 10:59:31 I'm trying to solve a 'funny' in https_dns_proxy Jul 24 13:27:08 Hi nbd, do you know what patch fixed the issues here https://github.com/openwrt/mt76/issues/193? Jul 24 14:04:49 blocktrron: sorry, fell asleep. if you're still there, this is not yet tested, but here is what i originally intended when i first wrote that patch: https://github.com/danielg4/openwrt/blob/bsap1920-testing/target/linux/ath79/patches-4.19/997-device_tree_cmdline.patch Jul 24 20:16:37 Is it really this quiet today/tonight? Jul 24 20:17:50 :[ Jul 24 20:26:35 yes Jul 24 20:26:36 at least in europe it's pretty hot (~37°C over here today, still around 29°C at 22:25 local time, and it won't drop below 22°C for the remainder of the night), that might not sound like much to warmer climates, but it's less common here/ less prepared for (houses being built to withstand cold/ wet weather, to keep the heat in) Jul 24 20:27:37 anyone seen this error message under system > led configuration Jul 24 20:27:39 TypeError Jul 24 20:27:39 can't convert null to object Jul 24 20:27:39 at render (http://192.168.1.1/luci-static/resources/ui.js:31:530) Jul 24 20:27:39 at renderWidget (http://192.168.1.1/luci-static/resources/form.js:158:702) Jul 24 22:20:44 * russell-- was in berlin and paris, managed to dodge the hot weather, it was lovely 20°C-ish the week he was in berlin. Jul 24 22:22:33 yep, the last two weeks were nice and cool, it only started to get hot again this week Jul 24 22:56:39 * russell-- wondering when the mt76 patch is going to be commited Jul 24 22:59:33 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=09c33df76fb88d80a804dc128f7bd08c361e998b ? Jul 24 23:46:49 pkgadd: yes, that seems to be it Jul 24 23:51:06 it fixed my dir860l image, no longer panics ;-) **** ENDING LOGGING AT Thu Jul 25 02:59:57 2019