**** BEGIN LOGGING AT Tue Jun 30 02:59:57 2020 Jun 30 08:33:25 andy2244: thanks for the patched up liburing Makefile Jun 30 08:34:18 I additionally have to fix int64_t support for mips32 Jun 30 08:36:21 Not sure what's the best approach to fix it. TARGET_CFLAGS+=-Dint64_t=__int64_t works fine in conjunction with ifeq ($(CONFIG_CPU_TYPE),"mips32"). However, it feels like a hack Jun 30 08:43:52 Ok I just realized mips 74kc also has no int64_t for whatever reason. I guess I will patch the configure-script to check for int64_t support. Annoying though... Jun 30 08:56:15 gladiac13375: that sounds odd. int64_t is defined by stdint.h Jun 30 08:56:26 but maybe I am missing some context here Jun 30 08:59:29 seems i've been away for two days Jun 30 08:59:30 oh well Jun 30 09:10:34 jow: True. They botched their handwritten configure-script. It checks for several special structs and if they are absent it adds the missing structs to a compat.h file. However, they #include after defining the structs which have int64_t variables. Oh well... Jun 30 09:14:59 gladiac13375: probably was written with x86 / glibc semantics in mind Jun 30 09:16:39 Alright, I just fixed it. It works now for mips32 and mips 74k Jun 30 09:16:58 jow: Hi! Did you get my rationale for removing tmp-on-zram from procd, yesterday? :) Jun 30 09:37:56 rsalvaterra: yes Jun 30 09:44:19 andy2244: I just created the liburing PR: https://github.com/openwrt/packages/pull/12656 Jun 30 10:47:05 Thanks PaulFertser Jun 30 10:52:32 Neighbor11111115: that SDR project should have everything needed for real-life communication, including noise measurements. You should talk to them if you're into related research. Jun 30 10:54:07 PaulFertser, I'm very much a noob in the whole area. But I'm very interested in learning. This project looks amazing. A few steps ahead of my current skill-level. My current plan is to play around with mt76 to learn 802.11 MAC details (and Linux integration). I've also got a HackRF so I'm gonna start learning about phyiscal layer. Really excited :D Jun 30 11:00:20 does Jouni Malinen visit IRC ? Jun 30 11:02:51 is it possible to make board-detect/config-generate produce a network config, which creates a tagged interface for lan (eth0.1) and tagged for wan (eth0.2) but does not create a switch config part, but leaves the switch configured like it was at boot? Jun 30 11:04:26 it seems board.json assigns roles to each switch port. when i ommit the roles will the switch part in the network config just be empty? Jun 30 11:21:17 hbug: no, this is currently not implemented this way Jun 30 11:21:45 hbug: or rather, instead of ucidef_add_switch ... you'd simply use ucidef_set_lan_wan eth0.1 eth0.2 Jun 30 11:22:04 (written from memory, actual function names might differ slightly) Jun 30 11:22:28 this will generate a network config that uses eth0.1 and eth0.2 respectively without adding any switch configs Jun 30 11:24:04 jow: thanks i was wondering if ucidef_set_lan_wan eth0.1 eth0.2 does the trick for actually creating the tagged interfaces. does config-generate create the tagged stuff or is netifd it somehow infering from the name ending with .1/.2 ? Jun 30 11:24:37 kab-el: I don't think so Jun 30 11:26:39 i just realize i can test all this stuff. i was always flashing the modified firmware hoping it works this time. but now i realized i can just use a standard image and modify board.d and call board-detect and confi-generate manually and then examine the config files. Jun 30 11:27:03 i feel a little dumb now :D Jun 30 11:30:42 hbug: yes, netifd infers it from the name Jun 30 11:30:57 any foo.# will cause it to create an 802.1q vlan with id # Jun 30 11:59:55 jow: thank you. was always wondering where the magic happens. Jun 30 12:01:31 will adding foo.X.Y make and dot1q X and an dot1ad device top? :D Jun 30 12:29:31 jow:is luci providing an operator overload for "mod" to make the templates work? like here: https://github.com/openwrt/luci/blob/master/modules/luci-base/luasrc/dispatcher.lua#L716 Jun 30 12:29:53 I'm looking at letting sysauth.htm at least be provided by themese, ifnot totally freeform Jun 30 12:32:27 karlp: yes Jun 30 12:32:37 can i somehow apply a kernel patch only for a specific target? i now have it in linux/ipq40xx/patches-4.14 , but this applies it to every ipq40xx device and not only the fritxbox4040. Jun 30 12:33:05 where is thatimplemented? Jun 30 12:33:22 karlp: the luci.util class registers a __mod mete method on the string metatable which turns the LHS into a forma string template and the RHS into arguments to it Jun 30 12:33:25 sec Jun 30 12:33:34 (I'mjust trying to figure out how it gets some things from theme and others from the view/ directory Jun 30 12:33:40 https://github.com/openwrt/luci/blob/master/modules/luci-base/luasrc/util.lua#L30 Jun 30 12:34:06 oh, it'smagical whenever luci.utilis required. cute Jun 30 14:22:42 jow: so, I've done this for theme provided optional sysauth, ~similar to how themese provide header/footer and they're included from thebase module, doesthis approachlook reasonable? https://paste.centos.org/view/9c1c1eb7 Jun 30 14:23:07 I don't see any need for the custom sysauth template for every node that the old style allowed, one per theme seems more thansufficient? Jun 30 14:48:45 karlp: I like the idea of making the sysauth page theme specific Jun 30 14:49:51 karlp: what about moving sysauth.htm into each theme and removing the generic one completely? Jun 30 14:50:22 also ok with me really. Jun 30 14:50:33 I just went with this to not break everyone :) Jun 30 14:51:03 given that the header.htm normally has behaviour based on login, I do think they should go together. Jun 30 14:51:27 we could do one for 19.07 and require it in master? Jun 30 14:51:53 (1907 lost the abiity to do sysauth templates at all, which is why I'd like to see it go to 1907 at least) Jun 30 14:53:25 hmm Jun 30 14:54:37 I can edit the in-tree themes, but I'm ~pretty sure there's out of tree themes that would perhapsnot appreciate failinguntilthey provided (a copy) of sysauth.htm? Jun 30 14:54:52 what is preventing you from simply doing <% include("themes/" .. theme .. "/sysauth") %> in the generic sysauth.htm ? Jun 30 14:55:35 trying to understand the scoping changes you did Jun 30 15:05:44 karlp: can you try this alternative approach? http://sprunge.us/I3NvQV Jun 30 15:12:01 include throws a hard error() if thetemplate it tries to load cna't be found Jun 30 15:12:26 that'swhy I needed "some form of pcall" andthat needed a copcall, so I didn't get "attempt to yield across metamethod/C-call boundary" Jun 30 15:12:56 andusing util.copcall gave me a "invalid fenv index" so I just guessed I wasn't as deep in the stack andhacked it in as a parameter Jun 30 15:13:20 changing include to return an error instead of raising one seemed a lot more invasive Jun 30 15:13:25 for ~minimal gain. Jun 30 15:13:53 that does look nicer :) trying it now :) Jun 30 15:15:07 its totally untested, you might need to change pcall to copcall Jun 30 15:39:37 yeah, itneeded util.copcall. didn't get _anything_ with the pcall, just plain html raw dump, and nothing on the console Jun 30 15:39:51 yeah, that's really nice :) Jun 30 15:42:02 can you make a PR? Jun 30 15:42:13 https://paste.centos.org/view/d2995d35 I can have tested by, but you wrote it? Jun 30 15:42:47 aye, will merge that one Jun 30 15:42:57 for 1907 too please :) Jun 30 15:43:41 (iv'e not tested it on master yet, that'sstillbuilding to test my earlier one) Jun 30 15:44:08 but that code hasn't changed, I wouldn't expectany difference Jun 30 15:49:51 I am toying with the idea of adding a kind of include_theme() function which encapsulates that logic Jun 30 18:03:39 Is the forum down? Jun 30 18:03:58 I keep getting "The site at https://forum.openwrt.org/ has experienced a network protocol violation that cannot be repaired." Jun 30 18:11:53 loads for me Jun 30 18:12:20 It's back now Jun 30 18:12:42 DonkeyHoteiThank you for checking for me, though! :) Jun 30 18:47:07 I found a reference to some "openwrt firmware" in the firmware of the TP-Link EAP245v3. Does anybody recognise this? https://github.com/svanheule/tplink-fw-3rd **** ENDING LOGGING AT Wed Jul 01 03:01:14 2020