**** BEGIN LOGGING AT Sat Dec 05 02:59:57 2020 Dec 05 07:44:23 stintel: yeah Dec 05 07:44:34 we should just drop all the mini targets Dec 05 07:44:48 concentrate on the ones that have a large userbase Dec 05 07:45:11 I would even vote for fropping additional gcc versions and libc versions Dec 05 07:45:24 there should just be 1 gcc and 1 musl Dec 05 07:46:01 move all targets to a feed on github. if anyone want to maintain them fine, otherwise not Dec 05 07:46:52 we should also consider to use crottools-ng to build our toolchains, yet another big chunk of code gone that we need to maintain Dec 05 07:47:06 *crosstools-ng Dec 05 09:09:15 blogic: as far as I understand it, uClibc-ng was first. then most stuff migrated to musl. now it's only kept for ARC. as for glibc, ??? Dec 05 09:09:52 I think I'll get rid of libcxx Dec 05 09:14:29 ynezz: did you nuke the failing builders already? I guess they crashed mid-build Dec 05 09:17:23 mangix: yes Dec 05 09:17:42 mangix: arc folks had several years to remove the dependency Dec 05 09:19:38 ok, that git lock is still there, I'm cleaning them up Dec 05 12:23:31 I'm all for burning arc. snps has had MOUNTAINS of time to come back and help do the work themselves. Dec 05 13:02:50 nbd: Don't think we need need the clang wrapper anymore https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=8c11c21509c819a305c71071f530bd578b25cfd9 Dec 05 13:41:48 anyone else find that master doesn't build? Dec 05 13:41:54 feeds update fail due to inexistant commits, build fails Dec 05 13:42:33 well, feeds update throws a warning that is. build fails due to something, something, sstrip Dec 05 14:08:10 shibboleth: could you please post the error message to pastbin Dec 05 14:08:21 i did in the other chan Dec 05 14:08:33 https://paste.debian.net/hidden/a398e619/ Dec 05 14:45:29 anything? Dec 05 14:45:57 i've just retried with a clean clone, spotted an error 20 minutes into the compile Dec 05 16:07:30 kmod-wil6210 seems to have disappeared as an option in menuconfig? Dec 05 16:09:45 shibboleth: for me it is compiling fine Dec 05 16:09:54 I think we never had wil6210 Dec 05 16:10:31 yes,i spotted several "red" errors during compile but it did go through after purging the local clone Dec 05 16:10:44 make clean/git reset/git clean did not work Dec 05 16:11:10 but, less than a month ago wil6210 was an option and now it seems to have gone poof Dec 05 16:12:41 the firmware is there, kmod not so much Dec 05 16:14:18 anyone have a copy of master, care to do a make menuconfig and see if kmod-wil6210 is there under kmod->wireless? Dec 05 16:14:52 build also ignores manual selection in the config Dec 05 16:14:58 -file Dec 05 16:17:35 ah, 8eeb57acb75f9d89abed59595de052dba9fed7b8 again Dec 05 16:17:53 why was it explicitly disabled? Dec 05 16:18:04 shibboleth: checked master and it is not there. Dec 05 16:18:59 damex, thanks. yeah, that commit has me wondering Dec 05 16:20:02 is it safe to patch it or is there a specific reason why nbd "blacklisted" it? Dec 05 16:21:10 or is git log playing with me again? Dec 05 16:26:43 shibboleth: i "blacklisted" it? Dec 05 16:27:01 i can't find any commit where we ever packaged it Dec 05 16:27:46 nbd, yeah, git log was playing with me, 3b1fa12cb9546eb29a9245968daddcdc6be4c27f was being shown as a split under 8eeb57acb75f9d89abed59595de052dba9fed7b8 Dec 05 16:27:59 heh, commit from 2013 Dec 05 16:28:10 indeed Dec 05 16:28:28 it wasn't packaged then, that commit just disables building unpackaged code... Dec 05 16:29:22 yeah, somehow my patches have broken some time in the last couple of weeks Dec 05 17:34:46 zorun: no, I just get back home Dec 05 17:56:27 jow: what does `ip rule add from x.x.x.x table nnn` look like in /etc/config/network? I can’t get it to work. bug? Dec 05 17:57:17 should just take `option src x.x.x.x` and `option lookup nnn` but that’s not adequate it seems. Dec 05 18:05:32 and after the validation in /etc/init.d/network, where does the actual work happen? Dec 05 18:06:25 ynezz: np, it's just that the errors stopped after some time, so I was wondering Dec 05 18:06:33 but it's just because there was nothing left to build :) Dec 05 18:13:57 for some reason, and most likely as a result of me having to purge my local repo wil6210 no longer appears in the kmod->wireless menuconfig Dec 05 18:14:06 where would i look to add it? Dec 05 18:14:19 anyone doing advent of code? Dec 05 18:14:27 maybe we can make an OpenWrt leaderboard :) Dec 05 18:15:00 i did add both the firmware and kmod to the device makefile and atk.mk Dec 05 18:15:01 philipp64: netifd I would say Dec 05 18:16:12 * rr123 somehow feel luci is much easier to hack comparing to client-side-js luci2, luci is only used rarely for configuration, is performance really that a big deal? I never saw luci became a performance issue in the past... Dec 05 18:20:55 zorun: I looked but couldn’t find it. Dec 05 18:21:57 oh, if this turns out to be fscache again i'm gonna lose it Dec 05 19:09:16 Re: disabling 802.11b by default, any objections to moving the "Allow legacy 802.11b rates" setting from Advanced Settings to the General Setup tab for visibility? Dec 05 20:11:27 mangix: I removed openvpn from openwrt.git, thanks Dec 05 20:48:20 rr123: I find hte performance to be a big change actually, even just as far as usability goes, even if it's "only" for config Dec 05 20:48:45 I fully agree, the beginnings of doing thins in js have eeb hairy for peopleused to the other ways, but I'm generally happy now. Dec 05 20:48:59 the most black magic bits are maybe hte menu.json and acl.d stuff Dec 05 20:49:18 you can still keep doing lua controllers though, and lua templates, they're still easier for somet things. Dec 05 20:49:41 but just having all the js apis in place actually made lots of lua custom controller stuff drop away for me at least. Dec 05 20:50:59 I eally don't like the "construcing html via chained E() calls, I think that's horrific, but you can still do "views" that are html first, and just don't expect to do inline lua, and htat's pretty fair tradeoff Dec 05 21:17:32 karlp: I wish there are some high-level document for the new luci, I know jow is super busy, hope someone can write up something :) Dec 05 21:18:10 "quickstart for the new luci", or something like that Dec 05 21:21:07 can luci just provide uhttpd-mod-ubus http calls, a simple rest api basically, to decouple the client from openwrt further Dec 05 21:23:55 After a successful build are the compiler logs kept? Dec 05 21:26:59 ByteEnable: you can enable it under "Advanced configuration options for developers" Dec 05 21:27:06 you will get a log/ directory Dec 05 21:27:34 or just redirect your make output Dec 05 21:29:13 IIRC invoking make with BUILD_LOG=1 will also get you the logs Dec 05 21:30:12 indeed Dec 05 21:33:39 * rr123 recently got quite a few yocto contract offers, the benefit of an over-engineered system for developers :) Dec 05 21:47:51 rr123: thanks man! Dec 05 22:10:39 rr123: the json-rpc apis are pretty much that now Dec 05 22:10:58 it's still a lot of "read the rest of the files in luci applications" Dec 05 22:11:07 but the api docs are a lot better than they used to be. Dec 05 22:11:12 and there's _more_ example apps now too. Dec 05 22:25:50 Seeing the following… guessing it’s extremely bad: Dec 05 22:25:51 [ 34.776767] netifd[9540]: segfault at 10c ip 00000000004113ac sp 00007fff497e7260 error 4 in netifd[404000+18000] Dec 05 22:25:52 [ 34.801335] Code: 01 00 59 5e 40 88 ab 09 01 00 00 48 89 df 58 5b 5d e9 61 ff ff ff c3 80 7f 18 00 0f 84 93 00 00 00 53 48 8b 5f 28 c6 47 18 00 <8b> 83 0c 01 00 00 ff c8 89 83 0c 01 00 00 f6 05 b7 7b 01 00 02 74 Dec 05 22:30:49 anyone who knows how the packages ci stuff around to help me setup locally? https://github.com/openwrt/packages/pull/14137 I know it's late saturday night. Dec 05 22:31:06 it can also wait, just had some time, thought i'd try, but local builds I can't reproduce it. Dec 05 22:35:37 the "## Continuous Integration Dec 05 22:35:53 chapter in Contributing has at least some docs on the test.sh magic, but nothing on setting up how the sdk builds work Dec 05 22:42:33 I have no idea how to turn https://github.com/openwrt/packages/blob/master/.github/workflows/multi-arch-test-build.yml#L51 into something I can do locally Dec 05 22:43:27 ah, brainwave, I think it references https://github.com/openwrt/gh-action-sdk/blob/master/entrypoint.sh Dec 05 22:50:12 not sure how it builds variants though Dec 05 22:53:08 would https://github.com/openwrt/gh-action-sdk/blob/master/entrypoint.sh#L85 not be better to just enable log files and cat the probelmatic packagfe's file, rather than rebuilding it? Dec 05 22:53:30 guess I shouldn't talk when I a) can't actualyl reproduce it and b) my packages don't pass Dec 05 23:00:45 ok, I can reproduce it now. Dec 05 23:01:18 it happens for building both variants in the same tree, and a package config that has a DEPENDS on one variant Dec 05 23:01:26 but DEPENDS only blocks whether you can set it Dec 05 23:01:29 once it's set, it's set... Dec 05 23:02:14 for the bored on saturday night crowd: https://paste.jvnv.net/view/oXEeC Dec 05 23:05:12 who builds both options at the same time.... :) Dec 05 23:06:36 ynezz: c9c7b4b3945c01c2aadf3ef5d9a77c8200db80f1 on 19.07 breaks xtables-addons-2.14 for me over at gluon, see https://paste.lossy.network/646A Dec 05 23:07:29 nice domain :) Dec 05 23:07:34 thx :) Dec 05 23:11:15 umm. any problems if more people use it? Dec 05 23:12:07 the paste? not at all Dec 05 23:22:34 does it happen to also support a curl et al interface? Dec 05 23:27:17 karlp: uhm, it has an api, https://github.com/supakeen/pinnwand/issues/100 is probably the issue Dec 05 23:27:32 oh, it's not. Dec 05 23:27:57 https://github.com/supakeen/pinnwand/issues/32 Dec 05 23:28:23 could voice your interest over there, I'm the last commenter in that issue already :) Dec 05 23:45:39 hexa-: I'll have a look Dec 05 23:45:59 thx Dec 06 00:09:42 aparcar[m]: next up, lzo :). lzo was used by openvpn. now nothing uses it. Dec 06 00:10:14 lzo is also used by zram, no? Dec 06 00:10:49 zram uses the kernel stuff I believe Dec 06 00:10:55 not liblzo Dec 06 00:11:22 true that: kmod-lib-lzo Dec 06 00:11:57 lzo is pretty old to be honest. better stuff exists Dec 06 00:12:07 mangix: uhm sure Dec 06 00:13:32 I think lz4 compresses better and is faster than lzo. let me check Dec 06 00:14:23 yeah Dec 06 00:14:42 oh that's painful Dec 06 00:14:53 lz4 uses more RAM Dec 06 00:15:12 therein lies the rub! Dec 06 00:15:24 13MB vs 0.2MB Dec 06 00:15:31 that's...quite the difference Dec 06 00:16:02 ouch Dec 06 00:17:05 cpu overheads are higher too, no? Dec 06 00:18:53 doesn't look like it Dec 06 00:18:58 lz4 compresses faster Dec 06 00:19:45 also decompresses faster Dec 06 00:19:49 but that memory usage... Dec 06 00:20:01 lz4 also compresses smaller Dec 06 00:20:21 "LZ4 generally offering the best performance with least CPU usage." Dec 06 00:21:09 it's interesting in that facebook people mostly focus on zstd, which is lz4 + coding Dec 06 00:21:33 apparently there are methods to reduce lz4 mem usage. Dec 06 00:21:39 https://github.com/apache/incubator-pegasus/pull/217 Dec 06 00:21:43 I'm sure many improvements could be backported to lz4 from zstd Dec 06 00:22:28 oh, wait, that's talking about ram reduction of snappy. nevermind. Dec 06 00:23:06 still, a useful comparison table on that link. Dec 06 00:24:08 zstd slower than lz4 to decompress. Dec 06 00:24:22 better ratio, slower decompression. Dec 06 00:24:23 yeah the coding scheme slows it down Dec 06 00:25:25 aparcar[m]: when merging patches from patchwork, you want to change the state to accepted Dec 06 00:25:40 so they get removed from the list Dec 06 00:26:44 dorf: RAM usage is not a concern in most circumstances. but this is OpenWrt Dec 06 00:26:56 hence why people recommend LZ4/ZSTD Dec 06 00:27:05 indeed, indeed. Dec 06 00:28:12 I feel somewhat blessed with the 500MB available here, and somewhat cursed by the firmware blob :) Dec 06 00:28:38 what device? Dec 06 00:28:49 wrt1900acs Dec 06 00:29:07 I have 8GB on mine Dec 06 00:29:20 storage, you mean? or ram? Dec 06 00:29:24 storage Dec 06 00:29:28 RAM is 2GB Dec 06 00:29:36 yeah, 8GB storage on the wrt. Dec 06 00:29:57 It's a Turris Omnia. Based on the same platform as the WRT devices Dec 06 00:30:26 yeah, nice looking device, albeit a bit expensive. Dec 06 00:30:30 The whole point of the router is to be overkill to be honest. Dec 06 00:32:55 bought the wrt second hand for around $100US, suits me.. runs as a client, no problem with perf. Dec 06 00:34:59 right. the platform is solid Dec 06 00:35:00 it annoys me that marvell/nxp/belkin aren't coordinating on full opensourcing of the firmware, but other than that, no regrets. Dec 06 00:35:41 right. that's one of the problems. the other is USB compatibility. Dec 06 00:36:25 haven't experienced that issue. 2 thumb drives plugged in fine, one running as exroot, the other as swap. Dec 06 00:36:27 One of my USB SATA interfaces can connect, the other can't. Dec 06 00:36:45 Also, USB power between both ports is shared Dec 06 00:36:58 The Turris Omnia having two USB ports was a bad idea. Dec 06 00:37:24 one for storage, one for printer. sane in principle. Dec 06 00:37:43 Right. But on most platforms, USB power is not shared. Dec 06 00:37:57 yeah, I hear you. Dec 06 01:35:00 interesting. pkgconfig also looks for files in /usr/share/pkgconfig Dec 06 01:35:13 there's only a single package in OpenWrt that installs to there. Dec 06 02:36:17 The master is using a 5.4.x kernel. I noticed in the build make menuconfig the only selection for MVEBU based boards is a lump of 370/375/385. Whereas the 5.4 kernel offers granularity to only select the 38X based SoC's. Are there reasons for this? Dec 06 02:52:20 ByteEnable: no idea what that means. Dec 06 02:52:36 there are multiple mvebu platformas Dec 06 02:52:39 *platforms Dec 06 02:55:54 CONFIG_ARMADA_370_CLK=y Dec 06 02:55:55 CONFIG_ARMADA_370_XP_IRQ=y Dec 06 02:55:55 CONFIG_ARMADA_370_XP_TIMER=y Dec 06 02:55:55 # CONFIG_ARMADA_37XX_WATCHDOG is not set Dec 06 02:55:55 CONFIG_ARMADA_38X_CLK=y Dec 06 02:55:55 CONFIG_ARMADA_THERMAL=y Dec 06 02:55:57 CONFIG_ARMADA_XP_CLK=y Dec 06 02:56:53 From 5.4. If I manually make menuconfig and select the SoC which is a 385 used by my wrt3200acm, only 38X is selected in the config. Dec 06 02:57:27 In the openwrt build it is selecting all ARMADA devices. Dec 06 02:58:02 expected behavior Dec 06 02:58:52 Then there is really no diff between Armada 370 vs 385? Dec 06 02:59:21 From what I can tell it is being used to select the boot and dts sutff. Dec 06 02:59:44 different dts files are used but same kernel Dec 06 02:59:51 I just haven't looked at how deep those options might go. So that is why I am asking. **** ENDING LOGGING AT Sun Dec 06 02:59:56 2020