<philipp64>
jow: Can we promote Thermi to reviewer/committer for packages?
<philipp64>
stintel: do you have a view on that, either way?
danitool has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<Pepes>
philipp64: jow: first we need to figure out to whom we are going to give commit access based on this issue https://github.com/openwrt/packages/issues/15257 otherwise we would end up with the situation that everybody can ask for commit access for his/her co-workers or friends w/o doing anything, though. That's why I don't like this approach as commit access access can be given
<Pepes>
to ja-pa, Python maintainers such as commodo, jefferyto and many others guys who sent more than PRs and reviewed PRs than Thermi, just my two cents on this thing.
<Pepes>
On the other hand, it does not matter if there is any maintainer, commiter, etc as mangix merges PRs not matter what and then this situation like this one https://github.com/openwrt/packages/pull/15853h happens
<philipp64>
Pepes: what's the chance of their being any sort of consensus soon? that's been in the wind for a while now...
<Pepes>
philipp64: I think the discussion were raised because you asked for it earlier and we should sort it soon, 'cos it's unfair for others as I mentioned.
<philipp64>
it's also unfair to keep would-be contributors in limbo indefinitely.
<philipp64>
or at least, not very good for recruitment.
<Pepes>
What's wrong to send PRs? It is at least compile tested by Github Actions and it can be tested by using test.sh file. Recent contributors removed PR templed, so there was no indication of anything.
<Pepes>
I haven't seen Thermi much to review things and send so many PRs than others. Still the same question. We need to have rules for everyone. Otherwise, I can ask for a friend to have commit access as well who sent 2-3 PRs and he will get it, right? I think you can see my point and that's why there was created the issue there.
<aparcar[m]>
mangix: thanks that was quick
<aparcar[m]>
I left a comment
<philipp64>
Pepes: he reviews strongswan related stuff.
<Pepes>
I know that he cooperates with you on strongswan, but I still I don't see very good approach to just come to IRC channel and say, c'mon he deserves it, so let's give him commit access w/o doing some votes about it. Why he should receive commit access just for one package? Isn't enough to me maintainer? I am just trying to say that there are many better candidates to get commit
<Pepes>
access who are not using IRC channel for various reasons. Because on your approach everyone can get it if you know someone from pub. TBH you haven't said why he should receive it. I think I gave a valid reasons why I'd prefer that Python maintainers would have commit access.
<Pepes>
But I suppose you don't need to convince me at all as I can not give any commit access, but just saying pros and cons about it and how do I see it and that's why the GitHub issue was created in the first place.
<Pepes>
As small nitpick in the end I can see that there was created only one PR by that guy.
<aparcar[m]>
mangix: what would be a good candidate for a switch?
<mangix>
aparcar[m]: switch as in networking switch?
<slh>
that was my first response as well ;) but I think he refers to an ideal candidate (package) to switch-over from make to meson for its build process (util-linux-ng might indeed be a good candidate, as it's not necessary for normal installs)
<aparcar[m]>
mangix: no like what package should switch to meson building first
<aparcar[m]>
for testing
<mangix>
slh: util-linux meson is not yet merged I think
<mangix>
zstd kind of sort of supports meson
<mangix>
oh pkgconf does as well
<aparcar[m]>
mangix: well if all this is "experimental" it seems we should wait until meson got an actual use case
<mangix>
what's experimental?
<mangix>
openssl 3.0 RC is out. changelog sounds like it will be awful.
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Namidairo has quit [Remote host closed the connection]
Namidairo has joined #openwrt-devel
<philipp64>
I still don't think we need Meson. KISS and "if it ain't broke don't fix it".
<aparcar[m]>
philipp64: fair. I mostly looked into it to have APK building but i fixed it via makefile magic
<philipp64>
nothing too twisted I hope.
<philipp64>
poorly written Makefiles can be an abomination.
<aparcar[m]>
it's just about some flags I had to add which meson would have done automatically
<mangix>
philipp64: based on what aparcar wrote, it depends how you apply KISS
<mangix>
Ninja in base for example is not simple. But there's a clear benefit.
<philipp64>
mangix: true. I'm a big fan of autotools.
<mangix>
It's also not needed for now.
<mangix>
but still a good idea.
<philipp64>
mangix: and that benefit is?
<mangix>
philipp64: benefit is faster compiles and less or no breakage with parallel builds
<mangix>
manually written Makefile and automake stuff breaks easily when built with make -j X
<philipp64>
well, if people knew how to write their Makefile rules correctly, parallel breakage wouldn't happen.
<philipp64>
but I might as well say, "if pigs grew wings..."
<mangix>
not correct
<philipp64>
what's not?
<mangix>
the Makefiles generated by CMake are not all threadsafe
<mangix>
the build.ninja files are
<mangix>
meson projects (they use ninja) seem to have no problems either.
<philipp64>
I didn't mention CMake.
<philipp64>
CMake has its own problems.
<mangix>
Sure, but CMake allows switching between Unix Makefiles and Ninja
<mangix>
meaning you can somewhat compare between the two
<mangix>
meson is Ninja only
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<mangix>
whoa, synopsys owns coverity
<mangix>
*mind blown*
<dhewg>
did meson 0.58 bump the python requirements again?
<Pepes>
Strykar: be patient a little bit. ;-) It's good that you created issue, but I dont see here urguing the priority. hnyman is very active on GitHub and he will get to it soon.
<Strykar>
:)
_lore_ has quit [Ping timeout: 480 seconds]
<rsalvaterra>
This. I like this a lot. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c7182123b961fdc2991faa3806eb7156e14c3ff8
<rsalvaterra>
When the kernel partition is dynamic, having modules is counterproductive.
<rsalvaterra>
nbd: This is basically what I had since forever, with two exceptions… why do we need CONFIG_CRYPTO_GF128MUL and CONFIG_CRYPTO_NULL2? I don't select those and never had any crypto issues.
<rsalvaterra>
I wager GF128MUL is needed for GCMP, but is how widespread is it?
<nbd>
GCM selects GHASH, GHASH selects GF128MUL
<nbd>
gcmp is the new encryption added with 802.11ac
<stintel>
karlp: for me, at least one in every room, motion, pm, co2, temp/hum/... a couple for a friend, a couple for my parents' place, things like that
<rsalvaterra>
nbd: Hm… strange. I think it didn't select before, but I might be wrong.
<stintel>
philipp64: works for me
<stintel>
zorun: not sure why you're pinging me about that?
<rsalvaterra>
I think it's just explicit now, probably the same.
<rsalvaterra>
nbd: I guess the make kernel_oldconfig induced me in error, this is the diff to my previous kernel config… https://paste.debian.net/1201629/
<rsalvaterra>
nbd: Not, there's definitely a change, my kernel is 20 kiB larger.
<rsalvaterra>
*No
<rsalvaterra>
nbd: Found it. None of these are needed to get Wi-Fi crypto working, including WPA3 and OWE. https://paste.debian.net/1201637/
<rsalvaterra>
Oh, crap… I just saw this, nevermind… :/ https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=53b6783907f3bd6f0f88f9d6feed20b21e2cd181
<rsalvaterra>
*sigh*
decke has quit [Quit: Leaving.]
Rentong has quit [Remote host closed the connection]
<jow>
rmilecki: are you aware of the failsafe regressions introduced by the ifname->device migration?
<jow>
rmilecki: there's a bunch of target specific preinit scripts pulling the "ifname" property out of board.json, these probably need to be changed to "device"
<rmilecki>
jow: i was made aware today, will check them during weekend
<jow>
for the future we should consider /etc/board.json to be public API, there's also 3rd party stuff relying on it
<jow>
since it is pretty much the only way to obtain (some) default settings
dangole has joined #openwrt-devel
<dangole>
anyway had success with building LLVM/Clang (mainly for eBPF stuff) inside our buildsystem? or any ideas why Clang fails loudly while LLVM itself builds fine? see https://pastebin.com/k6DFK7s0
<dangole>
*anyone
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<jow>
dangole: iirc blogic tyoed with that
<jow>
*toyed
<dangole>
jow: he played with it on the target, but used local cross-compile builds (ie. outside of OpenWrt build system) to make his eBPF objects. that works of course, but having it somehow more integrated in the build system would be nice, as that would allow for having e.g. https://github.com/xdp-project/bpf-examples packaged properly
<jow>
rmilecki: just fyi, I think I figured out that "igmp_v3" option mistery... it was an swconfig option specific to the ar8327 backend driver
<jow>
rmilecki: it never had any effect in interface sections, whoever put it there was probably just cargo culting
<dangole>
jow: i'll just keep trying, looks like some include-path havoc, but i'm having a hard time to figure it out...
<jow>
rmilecki: it was only defined in "config switch" sections and only if the underyling driver was ar8327.c, apparently it flipped a register there to make IC recognize IGMPv3
<jow>
*make the IC
<zorun>
stintel: sorry, I meant rmilecki (you have the same color in my IRC client...)
<jow>
dangole: well, after learning about the requirements and cross compile madness I completely lost interest
<jow>
dangole: given that all it does in the end is compiling a simplified C subset into a RISC VM bytecode with a bit of ELF framing, I think that writing a custom whatever-to-eBPF compiler is a more worthwhile goal
Rentong has joined #openwrt-devel
<jow>
you don't need clang, libelf and all that crap for that
<dangole>
jow: i found it quite motivating that LLVM itself was actually way easier to build than it used to be in previous versions, quite straight forward...
<dangole>
jow: i agree, that LLVM and Clang are multiple overkill for the purpose...
<jow>
sorry, don't want a compiler on target to install bpf programs
<jow>
at least not one in the llvm/clang ballpark, feature & size wise
<dangole>
jow: that for sure not, but having it as part of OpenWrt-SDK-* would be nice (as in: would allow xdp/eBPF stuff to just work in the way people are using it outside of OpenWrt)
<jow>
yeah, I agree
<jow>
but that's not interesting enough for me personally :)
<jow>
but I know that you didn't ask for that, anyhow. Maybe try poking blocktrron
<jow>
erm sorry, blogic
aleksander has quit [Quit: Leaving]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<dangole>
i pushed my non-working current state into a staging tree at https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/heads/wip-llvm-clang
matteoscordino has joined #openwrt-devel
<dangole>
it's not complicated so far and already getting LLVM compiled (after 40 minutes on my rather new Rhyzen workstation just for that, that's about 3x of 'make clean ; make all' keeping all cores busy)
<dangole>
(ie. just LLVM is 3x more build time than all of OpenWrt together)
<dangole>
(and Clang isn't included in that yet, that's still breaking)
Rentong has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Speaking of Clang, is it true its LTO produces *larger* binaries? I've seen someone complaining about it in the lkml…
<dangole>
rsalvaterra: all i want from it is a nice way to build/package github.com/xdp-project/bpf-examples for OpenWrt...
* rsalvaterra
is interested in kernel LTO… but with GCC, not Clang.
<rsalvaterra>
dangole: Neat!
Tapper1 has quit [Quit: Tapper1]
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
<zx2c4>
dangole: this is unbelievably cool, eh?
<zx2c4>
was delighted toke did that
<dangole>
zx2c4: it was a surprisingly happy morning, i must say that.
<dangole>
zx2c4: now i just need to find a way to deploy that on OpenWrt... call me old-fashioned, but it's easier to patch the kernel than getting LLVM/Clang to build inside our build-system...
Rentong has quit [Remote host closed the connection]
<hauke>
stintel: the hifive unmatched is nice
<hauke>
a Allwinner D1 is on the way to me
<hauke>
xback: which rb912 target?
<tohojo>
dangole: yeah, we really need to fix the BPF deployment story on OpenWrt :)
<dangole>
tohojo: been starring at Clang build include havoc for while now, down to trying random things. WiP is here: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/heads/wip-llvm-clang
<dangole>
tohojo: and yes, imho we are missing out on eBPF coolness for a while now and having a toolchain capable of generating BPF objects included in SDK should have happened years ago. if LLVM just wasn't such a beast...
<tohojo>
Yeah, know what you mean. Doesn't help that the upstream kernel needs LLVM features that are not even in a release yet...
<tohojo>
When you do get it to work, feel free to open an issue or PR if you need any changes to the bpf-examples build system. It's not really geared for packaging, but we can fix that...
_lore_ has joined #openwrt-devel
<dangole>
tohojo: right now i'm still stuck with getting Clang to build at all inside OpenWrt's build system. feel free to checkout the wip-llvm-clang branch above, select LLVM and Clang in menuconfig (Advanced configuration options -> Toolchain options) and see things getting messy (after waiting a long time for LLVM to build, that does work already, just Clang build hits the wall right away)
<tohojo>
Heh, right. Not really my area of expertise I'm afraid... :(
<dangole>
dangole: finding the needly in the haystack of C++ headers...
<dangole>
tohojo: other than that your solution looks brilliant and we could use it right away -- the links are use exclusively for wireguard tunnels, one tunnel for each link :)
dangole has quit [Remote host closed the connection]