<guidosarducci>
ldir: great, two pointless responses on the dnsmasq list. One, a straight up "FU", and the other mostly ignoring my email to make irrelevant pedantic points demonstrating how smart they are. That sort of noise just kills discussion. :-/
papaja has quit [Quit: Connection closed]
dansan has quit [Quit: The C preprocessor is a pathway to many abilities some consider to be unnatural.]
<russell-->
guidosarducci: yeah, i've been busy (my build tree has been tied up doing deployment compiles), i'll try to look at it tonight. can you remind me of what testing you've done?
Grommish_ has joined #openwrt-devel
<guidosarducci>
russell--: I've built and run tested the 3 NLS-sensitive packages with interdependencies: binutils, bpftools and iproute2, using both musl and glibc as libc.
<guidosarducci>
russell--: this was on QEMU/malta/be32 with some run-time regression testing as well.
Grommish_ has quit [Read error: Connection reset by peer]
<russell-->
what tf is a ubi layer for but to mitigate these kinds of flash errors
<guidosarducci>
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.
<guidosarducci>
plntyk: if libbpf.pc were broken then the final link (after configure) wouldn't work either, but it does fine.
<guidosarducci>
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.
<plntyk>
ok - the patch naming (patches/190-...) had me a little bit confused - maybe the "link with ldflags" is better
<guidosarducci>
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...
<plntyk>
its only C++ potential breakage
<plntyk>
i think currently no package is using that combination
<plntyk>
the TARGET_NLS_LIBS var that could be set in Makefile is just more cosmetic then setting "TARGET_LDFLAGS+=-lintl" or similar solutions
dorf has quit [Remote host closed the connection]
<guidosarducci>
plntyk: I'm surprised nothing C++ has broken all these years. You sure we have no cpp with -lintl? What about other repos?
dorf has joined #openwrt-devel
<plntyk>
some longer time ago the CXXFLAGS were set to CFLAGS for example - but since cmake introduction that is removed
<guidosarducci>
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?
<guidosarducci>
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.
<plntyk>
yeah i am currently more busy with some polishing / changing other stuff like dvb and didnt had time to test that with real stuff
<guidosarducci>
plntyk: sure, understood. nothing broken so no great urgency.
<plntyk>
guidosarducci, yes - as NLS is auto-deactivated and several packages iirc are patching / removing that stuff too - removing .po subdirs and so on
<plntyk>
and the "use case" on a router is a little bit "strange" too
<plntyk>
it probably would only make sense on routers with attached LCDs for status messages or sth. similar
<plntyk>
something like that was crowdfunded some years ago afaik
<ldir>
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.
<guidosarducci>
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.
<guidosarducci>
ldir: that would be a nice speedup for address/server blocklists, though still secondary to fixing the OOM behaviour.
<ldir>
The response I got also pointed out the current linear search behaviour for address=/ foo lines
<ldir>
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
<ldir>
I'm assuming that this subprocess becomes an 'address sanitiser' - I wonder if this becomes a scheduling based bottleneck
<guidosarducci>
ldir: that actually sounds more complicated, doing IPC with another subprocess? Setting that memory read-only after setup seems simpler, but let
<guidosarducci>
^^^ let's see what Simon's thinking...
<ldir>
yep
slh64 has joined #openwrt-devel
slh64 has quit [Remote host closed the connection]
slh64 has joined #openwrt-devel
Tost has joined #openwrt-devel
danitool has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<ldir>
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
victhor has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
lemmi has joined #openwrt-devel
lemmi has quit [Client Quit]
lemmi has joined #openwrt-devel
Tost has quit [Ping timeout: 246 seconds]
<nbd>
ldir: looks good t me
goliath has joined #openwrt-devel
<ldir>
nbd: I was concerned by that extra fdb condition that's been added upstream.
<rsalvaterra>
ldir: Scared us both, heh? :)
<ldir>
filtering local IIRC
<ldir>
rsalvaterra: yeah! It's probably less scary if you know the intention of our patch :-)
<rsalvaterra>
Indeed… :P
ivanich has quit [Quit: Konversation terminated!]
Borromini has joined #openwrt-devel
<rsalvaterra>
Uhh… I'm detecting high bogosity levels in the build system.
<rsalvaterra>
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.
<rsalvaterra>
In other words, all Cortex-A7 CPUs have both VFPv4 and (64-bit) NEON.
muhaha has joined #openwrt-devel
<Hauke>
rsalvaterra: it looks like some targets only specify A7 and some A7 with neon-vfpv4
<rsalvaterra>
Oh, it's MT7629, it doesn't specify CPU_SUBTYPE. Fixing.
<Hauke>
on the Cortex A9 this was all optional, some targets have NEON some have vfpv3 and some vfpv3-d16
<Hauke>
rsalvaterra: thanks
<rsalvaterra>
Hauke: I'm doing the treewide kernel refreshes, so I'm noticing this annoyances. :)
<rsalvaterra>
*these
<rsalvaterra>
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
daregap has quit [Quit: daregap]
<Hauke>
rsalvaterra: I think you should seperate the UBI_FS changes from the refresh
<rsalvaterra>
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.
<rsalvaterra>
And with the MT7629 change, we have one less toolchain to build! ;)
Tost has joined #openwrt-devel
mgiganto has quit [Ping timeout: 240 seconds]
ivanich has joined #openwrt-devel
Tapper has joined #openwrt-devel
xback has joined #openwrt-devel
<xback>
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
<xback>
KERNEL_TESTING_PATVER moved to the subtargets
<xback>
but it looks like this makes the option unselectable?
<xback>
srry. was meant for blocktrron :-)
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
Borromini has quit [Ping timeout: 252 seconds]
Tapper has quit [Ping timeout: 240 seconds]
SamantazFox has quit [Ping timeout: 240 seconds]
Night-Shade has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
black_ant has quit [Ping timeout: 265 seconds]
Borromini has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 268 seconds]
victhor has quit [Ping timeout: 260 seconds]
SimJoSt has quit [Quit: WeeChat 2.9]
jlsalvador has quit [Quit: jlsalvador]
zkrx has quit [Ping timeout: 260 seconds]
Borromini has quit [Ping timeout: 252 seconds]
Tapper has joined #openwrt-devel
zkrx has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
Borromini has joined #openwrt-devel
mgiganto has joined #openwrt-devel
<mgiganto>
helloooooo
<mgiganto>
happy good friday!
<mgiganto>
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
kakaka has quit [Ping timeout: 240 seconds]
victhor has joined #openwrt-devel
kakaka has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
andi- has quit [Ping timeout: 268 seconds]
andi- has joined #openwrt-devel
dangole has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
Tapper has joined #openwrt-devel
muhaha has quit [Quit: Connection closed]
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
mrkiko has joined #openwrt-devel
<mrkiko>
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
<mrkiko>
I asked in #openwrt, got no answer until now... so was curious
<aparcar[m]>
guidosarducci: I pushed your buildbot libelf thing
<aparcar[m]>
I'll connect with ynezz on how to update the buildbot docker images
<xdarklight>
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
swex_ has quit [Quit: swex_]
rmilecki has quit [Ping timeout: 240 seconds]
swex has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
Tapper has quit [Ping timeout: 240 seconds]
<mgiganto>
The default configuration of my WRT32X (DSA) running master
<mgiganto>
(r16341+5-bbb9c1c2be) with 4 ports in an interface have all the 4 ports
<mgiganto>
UP/LOWER_UP. When I take one port away to punt it directly in a bridge
<mgiganto>
device, the port remains down, I tried some extra configs but it remains
<mrkiko>
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
<mrkiko>
even mounting the uSD card, creating a folder and umounting it results in FS corruption
<mrkiko>
I left the card active for some time, but didn't write much to it so I expected it to work fine
mrkiko has quit [Remote host closed the connection]
slh64 has quit [Quit: gone]
ivanich has quit [Quit: Konversation terminated!]
goliath has joined #openwrt-devel
<blocktrron>
xback: hmm, cant test this right now, but in the past i was able to select testing kernels @ath79
Tapper has joined #openwrt-devel
PkChU has joined #openwrt-devel
PkChU has quit [Remote host closed the connection]