**** BEGIN LOGGING AT Fri Apr 02 02:59:57 2021 Apr 02 06:38:01 guidosarducci, regarding your NLS fix in iproute2 Apr 02 06:39:04 shouldnt you change the libbpf.pc file so that "LIBBPF_LDLIBS=$(${PKG_CONFIG} libbpf --libs)" returns the correct flags ? Apr 02 06:40:35 plntyk: the libs are correct. Can you elaborate? Apr 02 06:44:55 the nls introduced error was / is through libbpf i assume since iproute2 doesnt have any "gettext" / intl code as far as i can see correct? Apr 02 06:45:09 plntyk: you've also said NLS is broken in the toolchain.. How exactly? Apr 02 06:45:23 guidosarducci: i'm not going to have time tonight to review your pr, chasing a squashfs error on ubnt-erx unfortunately Apr 02 06:46:14 russell--: ok, sure, just didn't want it forgotten as 21.02 approaches. I'll just keep bugging you ;-) Apr 02 06:47:01 plntyk: my PR fixes 3 different issues; are you talking about bpftools now, or iproute2? Apr 02 06:49:45 iproute2 - shouldnt LDFLAGS change be "pulled in" via pkg-config --ldflags or sth. similar in configure ? Apr 02 06:50:33 aka patch the libbpf.pc file more as it is already done Apr 02 06:52:06 http://sprunge.us/kAZjX7 Apr 02 06:53:15 what tf is a ubi layer for but to mitigate these kinds of flash errors Apr 02 06:54:53 plntyk: this isn't directly related to libbpf. The problem is that iproute2's configure uses a one-line CC invocation, which doesn't seem to pick up LDFLAGS from the environment. And that LDFLAGS includes an "rpath-link" set by our NLS package includes. Apr 02 06:55:40 plntyk: if libbpf.pc were broken then the final link (after configure) wouldn't work either, but it does fine. Apr 02 06:58:09 plntyk: the real problem is that the new upstream configure code does fragile test compile to detect libbpf rather that use pkg-config in the first place. Fixing that upstream would be a bigger separate patch, after which our fix would be unneeded. Apr 02 06:59:05 ok - the patch naming (patches/190-...) had me a little bit confused - maybe the "link with ldflags" is better Apr 02 06:59:20 -the Apr 02 07:00:27 regarding "other" NLS stuff - atm i only have https://gist.github.com/plntyk/a1ea29752ea801018795cd8294ea3491 added for "completion" Apr 02 07:00:37 locally Apr 02 07:01:30 and regarding the "-lintl" i just read last night the NLS / gettext (18.23 chapter) at https://buildroot.org/downloads/manual/manual.html Apr 02 07:02:13 plntyk: "190-fix-nls-rpath-link.patch" seems pretty clear, as it summarizes what I just said... let me have a look at the other thing... Apr 02 07:02:28 its only C++ potential breakage Apr 02 07:02:55 i think currently no package is using that combination Apr 02 07:04:50 the TARGET_NLS_LIBS var that could be set in Makefile is just more cosmetic then setting "TARGET_LDFLAGS+=-lintl" or similar solutions Apr 02 07:04:59 plntyk: I'm surprised nothing C++ has broken all these years. You sure we have no cpp with -lintl? What about other repos? Apr 02 07:05:46 some longer time ago the CXXFLAGS were set to CFLAGS for example - but since cmake introduction that is removed Apr 02 07:05:49 i think Apr 02 07:06:33 dunno if you want to try to have some "sample" package like https://github.com/plntyk/packages-tests that Apr 02 07:07:18 as sentinel or sth Apr 02 07:10:47 plntyk: this requires some careful archaeology to avoid breaking something too. Your sentinel would be a good test to convince people the change is needed, but maybe better to use some "real" software package? Apr 02 07:16:12 plntyk: your Makefile doesn't use a build system, so hard to say if one wouldn't handle the problem automatically. I'd check other repos for something C++ first, and raise it on the ML for devs. Apr 02 07:16:17 yeah i am currently more busy with some polishing / changing other stuff like dvb and didnt had time to test that with real stuff Apr 02 07:17:15 plntyk: sure, understood. nothing broken so no great urgency. Apr 02 07:18:18 guidosarducci, yes - as NLS is auto-deactivated and several packages iirc are patching / removing that stuff too - removing .po subdirs and so on Apr 02 07:18:44 and the "use case" on a router is a little bit "strange" too Apr 02 07:19:27 it probably would only make sense on routers with attached LCDs for status messages or sth. similar Apr 02 07:19:46 something like that was crowdfunded some years ago afaik Apr 02 07:19:54 or like the dvb stuff Apr 02 09:09:25 guidosarducci: I re-subscribed to the dnsmasq list and the 2nd email I got was the 'FU' response - but take courage, I've had a private response from Simon and he's interested in this (ab)use of certain dnsmasq mechanisms for adblocking porpoises..and resolving the OOM. Apr 02 09:12:43 ldir: heh, the 'FU' response was less of an issue, April 1 and all that. The other irrelevant stuff tends to hijack discussion. Good to hear Simon reached out. Perhaps I should add some more detail to the OOM mechanism, since some folks aren't seeing or ignoring it. Apr 02 09:15:56 ldir: BTW, since you follow the list, did this ever get done: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q1/009278.html Apr 02 09:16:20 ldir: which refers to: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q1/009257.html Apr 02 09:17:09 ldir: that would be a nice speedup for address/server blocklists, though still secondary to fixing the OOM behaviour. Apr 02 09:18:28 The response I got also pointed out the current linear search behaviour for address=/ foo lines Apr 02 09:20:13 the thought is to introduce some new keyword and a subprocess that reads/handles this keyword, building its own structure/memory, leaving the parent pre-bloat which can fork thin tcp children Apr 02 09:33:12 I'm assuming that this subprocess becomes an 'address sanitiser' - I wonder if this becomes a scheduling based bottleneck Apr 02 09:33:37 ldir: that actually sounds more complicated, doing IPC with another subprocess? Setting that memory read-only after setup seems simpler, but let Apr 02 09:34:01 ^^^ let's see what Simon's thinking... Apr 02 09:34:17 yep Apr 02 10:59:17 nbd: could you take a look at https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=9473df3c6eaeaf98bbcebe1d0ec7333561d7ef56 pls - I'm particularly concerned by pending patches 703,762 & 764 Apr 02 12:40:58 ldir: looks good t me Apr 02 12:53:08 nbd: I was concerned by that extra fdb condition that's been added upstream. Apr 02 12:53:36 ldir: Scared us both, heh? :) Apr 02 12:53:49 filtering local IIRC Apr 02 12:54:24 rsalvaterra: yeah! It's probably less scary if you know the intention of our patch :-) Apr 02 12:55:31 Indeed… :P Apr 02 13:40:41 Uhh… I'm detecting high bogosity levels in the build system. Apr 02 13:41:47 In the build_dir, I have both toolchain-arm_cortex-a7_gcc-10.2.0_musl_eabi toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.2.0_musl_eabi. Why, for Pete's sake? NEON isn't optional in Cortex-A7. Apr 02 13:42:34 In other words, all Cortex-A7 CPUs have both VFPv4 and (64-bit) NEON. Apr 02 13:49:50 rsalvaterra: it looks like some targets only specify A7 and some A7 with neon-vfpv4 Apr 02 13:50:16 Oh, it's MT7629, it doesn't specify CPU_SUBTYPE. Fixing. Apr 02 13:50:36 on the Cortex A9 this was all optional, some targets have NEON some have vfpv3 and some vfpv3-d16 Apr 02 13:51:00 rsalvaterra: thanks Apr 02 13:51:04 Hauke: I'm doing the treewide kernel refreshes, so I'm noticing this annoyances. :) Apr 02 13:51:19 *these Apr 02 13:53:19 Hauke: I don't know if you've seen my WIP branch. I'll have to rename it, since now it contains a LOT more than ubifs changes. :P Apr 02 13:55:03 rsalvaterra: I think you should seperate the UBI_FS changes from the refresh Apr 02 13:57:28 Hauke: Surely. What I'm not sure is if/how I should squash the refreshes. Right now, I have one commit per subtarget, but that's probably excessive. Apr 02 14:01:52 And with the MT7629 change, we have one less toolchain to build! ;) Apr 02 15:12:39 ynezz: Can I kindly ask you to share your 2 cents on this one? https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=e7acbd02af34782606efb7ebecf8c6b6e3062f31 Apr 02 15:50:12 aparcar[m]: Hi, quick question regarding: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=d6b785d47739a84611088ab26256fa5808d06a9d Apr 02 15:50:24 KERNEL_TESTING_PATVER moved to the subtargets Apr 02 15:50:34 but it looks like this makes the option unselectable? Apr 02 15:51:11 srry. was meant for blocktrron :-) Apr 02 18:30:04 helloooooo Apr 02 18:30:09 happy good friday! Apr 02 18:37:40 The default configuration of my WRT32X (DSA) running master (r16341+5-bbb9c1c2be) with 4 ports in an interface have all the 4 ports UP/LOWER_UP. When I take one port away to punt it directly in a bridge device, the port remains down, I tried some extra configs but it remains down. Example config: https://pastebin.com/ymz5sQGz Apr 02 20:57:05 Hello folks!! :) I would like to use openwrt in a 4G router with uqmi. Is there something in openwrt that natively handles disconnections? So when the bearer goes down it reconnects? Or is there any solutions for that? I dont know if the wwan or modemmanage protocol handler implements this Apr 02 20:57:18 I asked in #openwrt, got no answer until now... so was curious Apr 02 21:00:31 guidosarducci: I pushed your buildbot libelf thing Apr 02 21:00:42 I'll connect with ynezz on how to update the buildbot docker images Apr 02 21:53:31 Build [#17](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/29/builds/17) of `mpc85xx/p1010` failed. Apr 02 22:54:28 Hauke: it's me again :-). I am still testing but what do you think about https://pastebin.com/F1W92eQE ? if u-boot is overwriting this register then we're probably in trouble. I have proven that on my HH5A by un-setting GSWIP_MAC_CTRL_0_PADEN (as an example) and that breaks Ethernet Apr 02 23:15:28 The default configuration of my WRT32X (DSA) running master Apr 02 23:15:29 (r16341+5-bbb9c1c2be) with 4 ports in an interface have all the 4 ports Apr 02 23:15:29 UP/LOWER_UP. When I take one port away to punt it directly in a bridge Apr 02 23:15:30 device, the port remains down, I tried some extra configs but it remains Apr 02 23:15:30 down. Example config: https://pastebin.com/ymz5sQGz Apr 02 23:21:48 In ramips mt7621, is the mtk_sd driver we use the in-tree one or out of tree? I am having write issues on an SD card and am not sure if the SD card is broken or these are driver-related issues Apr 02 23:24:05 even mounting the uSD card, creating a folder and umounting it results in FS corruption Apr 02 23:24:23 I left the card active for some time, but didn't write much to it so I expected it to work fine Apr 03 00:12:52 xback: hmm, cant test this right now, but in the past i was able to select testing kernels @ath79 **** ENDING LOGGING AT Sat Apr 03 02:59:57 2021