guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<jow>
Mangix: unusual to see you being opposed to a version update ;)
<Mangix>
what makes you say that?
<jow>
Mangix: but in general I agree that it makes sense to be very conservative with the build tool requirements
<jow>
people can't comprehend that 10 year old openwrt releases are still actively used
<Mangix>
my reasoning is that updating meson bring no benefit and reduces comatibility for no good reason.
<f00b4r0>
heh. If I were a tiny bit sarcastic I'd say this PR is an excellent case in point not to move the whole build system to meson. Especially the first sentence of the last paragraph ;P
<Mangix>
meson 0.61 is not old at all...
<f00b4r0>
s/paragraph/comment/
<Mangix>
f00b4r0: not following
<f00b4r0>
Mangix: it boils down to: the build system itself will become a maintenance nightmare.
<f00b4r0>
would*
<Mangix>
ummm
<Mangix>
tools/cmake is a bigger maintenance nightmare
<f00b4r0>
tools/cmake doesn't break when an "old" python release is no longer supported.
<Mangix>
meson's dependency('iconv') doesn't have these issues
<jow>
it will have othere
<jow>
*others
<jow>
automake is also conceptually flawed and seriously broken in many cases
<jow>
yet it has to be supported for decades
<Mangix>
most broken stuff i've seen with meson is projects not using it properly (no usage of feature options). trivial to fix.
<jow>
same holds true for automake
<jow>
and autoconf
<jow>
yet projects will use it improperly
<jow>
anyhow, that isn't the point
<jow>
the point is that annoying yolo attitude of modenr software projects
<jow>
pyrthon with its constant deprecations
<jow>
and projects built on top it somehow mirroring that
<Mangix>
that applies equally to automake, cmake, meson, x, y, z.
<Mangix>
as far as the dependencies thing, cmake works around it by bundling everything and statically linking
<jow>
I'd say that 15 year old autoconf generated scripts have a higher chance to function compared to python code built 15 years ago
<jow>
likely whatever interpreter version it tageted is EOL
<Mangix>
I'd say the opposite unless we're talking about similar OS/userland. Everything breaks when something is updated.
ekathva has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
cmonroe has joined #openwrt-devel
robimarko has joined #openwrt-devel
<f00b4r0>
robimarko: hi, I tried building your PR for ipq40xx/mikrotik but it fails with: qcom-ipq4018-wap-ac.dts:206.1-7 Label or path gmac1 not found
<f00b4r0>
same error for gmac0 and gmac1 in fact
<robimarko>
Did you rebase it or?
<f00b4r0>
i was lazy so I checked out master at 3b7948474f where it applied without conflict :)
<robimarko>
I see its conflicting again
<f00b4r0>
yes with current master it does
<robimarko>
But WAP compiled, that issue is because those labels dont exist as there is just one gmac
<f00b4r0>
probably because of Pakedge WR-1 support patch
<robimarko>
It conflicts as new devices were merged yesterday
<f00b4r0>
yes, that's why I applied on a checkout from just before that
<robimarko>
Yeah, somehow wAP AC DTS slipped in with old nodes not removed
<f00b4r0>
i only stumbled upon this because the target builds all DTB regardless of which device is being built (I'm building for hap ac2), so it's a "lucky" find :)
<robimarko>
Yes, it recently switched to using buildroot provided DTB-s instead of having the kernel build them
<robimarko>
I pushed a rebased version with wap fixed
<robimarko>
Still need to fix the IRQ race nbd pointed out
<rsalvaterra>
FYI, I updated the MGLRU pull request with the ARM fix.
<robimarko>
BTW, what is KERNEL_DEPENDS doing?
<f00b4r0>
robimarko: ok thanks, I'll test again a bit later
danitool has joined #openwrt-devel
<rua>
Hello. I am porting openwrt to linksys ea4500 v3. Now I am able to load and boot an openwrt initrd image on ea4500 v3 via tftp, but the /etc/config/network does not fit it. (its default config should be like the one for tplink tl-wdr4900 v2)
<rua>
How can I set up the default network config for it?
<f00b4r0>
robimarko: built and booted fine. lan[1-4] match ports 2-5 (port 1 is WAN), so I think all is good. Anything in particular I should check?
Tapper has quit [Ping timeout: 480 seconds]
MaxSoniX has joined #openwrt-devel
ekathva_ has joined #openwrt-devel
ekathva has quit [Read error: No route to host]
<robimarko>
f00b4r0: Not really, just use it like you would and let me know if there is something broken
Tapper has joined #openwrt-devel
csrf has quit [Quit: Leaving]
<\x>
robimarko: is my testing wrong or does it really hit near wire speeds now on routing. WTF?!
<robimarko>
\x: Could be as nbd pointed out a IRQ race with threaded NAPI
<robimarko>
And that got "fixed" maybe/probably today
<\x>
i have to update the other ipq40xx that I use with this new one
<\x>
then i can proceed to test properly
<\x>
but yeah I dont get the thread stuck issue on dmesg anymore
<\x>
ill update later tonight when family is asleep
<\x>
robimarko: yesterday I actually deployed it just with napi disabled, seems those still has issue when getting hammered with ethernet, so yeah ill have to update those with current changes, itll take some time as its just 6:30 PM now here, I can prolly start around 10PM
<\x>
since family is using the internet
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
linusw_____ has joined #openwrt-devel
<robimarko>
\x: Wait, it was hanging with NAPI threaded disabled?
<\x>
yup robimarko
<\x>
it can hang even with "//dev_set_threaded(netdev, true);"
<robimarko>
Ugh, that looks like a generic regression
<\x>
well, I need to update that box with the current changes
<nbd>
Ansuel: the idea behind this logic is to suppress the auto-clean of a package if the build failed (or was not completed)
<nbd>
so that next time the build run gets to that package, it picks up where it left off (and is expected to fail in the same place)
<nbd>
instead of having to do the full package build from scratch again until it fails
<Ansuel>
nbd the problem i'm trying to understand is why the install is redone for host packages (with AUTOREMOVE on and host packages from another buildroot with AUTOREMOVE on) in rebuild_check the .install is failing (as he can't find the bin in build_dir) and the host package is clean-build (and rebuilt).... can't understand why the .install is not skipped like it's done for .prepared and .built. Don't know if you have any clue
<Ansuel>
about this
<Ansuel>
(i enabled some output that is muted to better understand this)
<nbd>
is this only about host packages in package/, or also about tools/?
<nbd>
ah, tools
<Ansuel>
this is about tools/
<Ansuel>
(that doesn't have the .autoremove file logic)
<Ansuel>
wonder if there is a problem with stamp of openwrt/staging_dir/host/stamp/.flock_installed
<\x>
robimarko: does ipq40xx even have proper context switching?
noltari has joined #openwrt-devel
ekathva has joined #openwrt-devel
noltari- has joined #openwrt-devel
<\x>
mehh and yeah so far, the crashes are random really if you use wifi with it, kinda annoyed and ill just test wired performance for now, really impressed that it can route gigabit maaan
<Ansuel>
makefile can correctly check the timestam of the .installed file and the install define is not called
<nbd>
it shouldn't check the time of the stamp dir at all
<nbd>
if it does, then that might be the bug
<Ansuel>
i know it's strange but the problem must be there. Could be that i'm wrong about the cause but it's definetly makefile having problem with timestamp for the .installed file
<Ansuel>
need to find why now
<Ansuel>
got this clue as we have every other ""stamp"" file (.prepared and .built) in the dedicated host package directory but for .installed we put everything in staging_dir/host/stamp and makefile redo exactly the install call
<Ansuel>
wonder if it's some kind of makefile refreshness problem and makefile thinks that file is old and needs to be recompiled?
noltari has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
noltari has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
f00b4r0__ has joined #openwrt-devel
f00b4r0__ is now known as f00b4r0
valku has joined #openwrt-devel
<Ansuel>
nbd false alarm... today i learned something new.... tar have problem with timestamp on extraction... in the sense that for some reason when with the option of removing timestamp he was extracting fist the staging_dir/stamp files and then the stuff in build_dir
<Ansuel>
this cause the staging_dir/stamp/.flock_installed to be older than the one in the build_dir
<Ansuel>
and FOR SOME REASON adding a directory make tar extract the staging_dir file AFTER the one in build_dir
<Ansuel>
so my ""fix"" was actually a placebo for another problem...
<Ansuel>
after 4 days i finally know what's wrong yay
<robimarko>
Ansuel: I doubt 6.0 will be LTS, usually its the last kernel release of the year
<robimarko>
\x: For cake CPU will always bottleneck
<f00b4r0>
robimarko: i didn't realize how much more idle power the hap ac2 draws vs hap ac lite. x2 is rather disappointing ;P
<robimarko>
f00b4r0: Well, they arent really comparable
<f00b4r0>
in raw horsepower they aren't, but the intended use is similar though :)
<f00b4r0>
in fact I was considering replacing my aclite
Tapper has joined #openwrt-devel
<robimarko>
Well, they kind of have the same intended usage
<f00b4r0>
but with the almost certain power cuts we'll have this winter, I might delay that a bit: my UPS holds out for 8h with aclite + ONT
<robimarko>
Dont think you are gonna find a more powerful device but have the same power consumption
<Ansuel>
robimarko same
<f00b4r0>
robimarko: I get that. I'd just wish the base load was lower. ARM is supposed to be all about power savings
<robimarko>
Well it is, but not compared to a single core MIPS with 802.11n
<robimarko>
You are asking the impossible
<f00b4r0>
+ac
<robimarko>
I can tell you that IPQ40xx consumption depends on the radios a lot
<f00b4r0>
ah
<\x>
its like 4W idle, with the radios being iperf'd its like 8~10W
<robimarko>
Yeah, worst case scenario with MCS0 should be 11.6W or something according to QCA
<robimarko>
This is worst case scenario and includes ethernet traffic as well
<f00b4r0>
interesting. I should do some proper measurements
<f00b4r0>
(and I should also get some spare UPS batteries ;P)
<\x>
how about 807x/60xx robimarko how are their power consumption?
<\x>
i just used a kill-a-watt on my measurement hehe
<robimarko>
I knew somebody measured it
<\x>
6W, so not a lot, thats nice
<robimarko>
It probably depends on radios a lot
<\x>
I wonder why cortex A53, not A35 so they could've been ready for the european energy crisis
<\x>
hehe
<f00b4r0>
;}
<robimarko>
Its not a new desgin
<\x>
start teaching your gear to consume bunker oil, that way you can save on electricity costs
<robimarko>
The CPU has been unchanged from the v1 SoC
<robimarko>
Which was draft 802.11ax
<robimarko>
So its 3+ years old at least
<\x>
robimarko im really impressed on what threaded napi has done to wired networking on this, so cool, from 500 to line speed on WAN -> LAN, no offloads and such, hella nice really
<robimarko>
I suppose balancing the IRQ-s could squeeze some more
<\x>
already hitting line speed man, need to overclock the nics first
<f00b4r0>
robimarko: until you hit cache locality issues maybe? Dunno how that arch's cache is architectured though
<robimarko>
f00b4r0: No idea
<f00b4r0>
worth a try i guess :)
<robimarko>
We are talking about whopping 256KB of L2
<robimarko>
\x: I have tried to make it panic today, ran iperf3 with multiple streams over wifi
<f00b4r0>
\x: not sure what I'm looking at
<robimarko>
And nothing
danitool has joined #openwrt-devel
<\x>
robimarko: its random, it might take time for you, but lets see if others will have issues or not, if none then my device has issues then
<robimarko>
I left it hammering with 4 parallel streams for like half an hour
<robimarko>
So, it was briding as well as routing at the same time
<f00b4r0>
wait what, you need help triggering some heisenbug? Let me have a go at it ;-D
<robimarko>
Seems so, one guy in the PR is hitting it reliably
<robimarko>
But I just cannot
<\x>
have a go f00b4r0, the way i can trigger it is by running an iperf server on the cable side, then your iperf client on the wifi side, then just hammer it
<robimarko>
\x: Thats what I did
<f00b4r0>
just to be clear, I need #4721 and?
<\x>
just 4721 then enable testing kernel (5.15)
<f00b4r0>
that's what I'm currently running
<robimarko>
No need, it became default today
<\x>
oh nice
<f00b4r0>
i'll give it a spin. But duty calls right now, bbiab
<robimarko>
nbd found a nice IRQ race, but that should be now sorted
<robimarko>
Was really hoping that to be the cause
<\x>
any chance that usin schedutil instead of ondemend was causing the issue? thats the only thing i touched on kernel menuconfig
<robimarko>
Seriously doubt that, especially since others are hitting it as well
MAbeeTT4 has joined #openwrt-devel
dangole_ has joined #openwrt-devel
<\x>
robimarko: you cant even get a dmesg log of it everytime it happens
<\x>
ill try to get one where it shows up on dmesg
<robimarko>
\x: Thanks, its just so weird it broke after last rebase even with threaded NAPI disabled
<\x>
getting the "hardware queue x is in stuck?" is once in a blue moon
<\x>
but yeah it can be got
dangole_ has quit [Quit: Leaving]
dangole_ has joined #openwrt-devel
<Ansuel>
well fk this i will use a workaround
<Ansuel>
tar mtime is a joke....
<jow>
isn't it supposed to exactly reproduce timestamps?
<\x>
doesnt always show up
<Ansuel>
jow conclusion is that tar is stupid and for some reason cause the stamp .installed to be extracted BEFORE the .prepared and .built
<jow>
so you're saying that after packing, transferring to another system, unpacking the timestamps are different and not even in a proper relation to each other?
<\x>
nevermind, my bad
<Ansuel>
makefile detect .installed as old ... rebuild_check detect this as package fail and clean the package
<jow>
Ansuel: which shouldn't be an issue because it should restore the file times after unpacking, so the order of decompression/unpacking /should/ not matter
<Ansuel>
and magic the package is rebuilt
<Ansuel>
jow for some reason having and old mtime cause all the package to be recompiled...
<Ansuel>
the current approach is
<Ansuel>
tar -x -m --mtime=now -f /tools.tar
<Ansuel>
find staging_dir/host/stamp -type f | xargs touch
<Ansuel>
With this flock (for example) is not rebuilt
<jow>
can you provide the output of tar -tf tools.tar ?
<Ansuel>
if file are extracted in the order of this output then it makes sense
<Ansuel>
--sort=name would be the trick here?
<Ansuel>
nope no change
<grift___>
is ujail used by default in the latest stable release?
<grift___>
i dont think i saw that mentioned in the release high lights and i dont use stable myself
<grift___>
but wondering about that
<jow>
Ansuel: --mtime does not apply to extraction
<jow>
Ansuel: it is for setting mtime on packing
<jow>
Ansuel: how do you create the tar?
f00b4r0 has quit [Quit: bbiab - electrical panel work]
<grift___>
i guess thats a negative then
<Ansuel>
jow oh.... i create tar with simply -cf
<jow>
grift___: well we already got bug reports about ujail breaking previously working configs, so yes it is there by defualt for some services, mainly dnsmaq
<grift___>
thanks jow
<grift___>
actually kind of surprising that we overlooked that in the high lights
<jow>
they miss most of the developments
<jow>
:)
<jow>
Probably because it is lots of smallish things, not so much big impact changes like fw4
<ynezz>
Ansuel: BTW I'm wondering why this toolchain/tools juggling, arent you recreating the SDK?
<Ansuel>
ynezz for the github actions
<Ansuel>
-20 minutes for the kernel workflow
<ynezz>
yes, but shouldn't it be possible to use the SDK for that?
<Ansuel>
can the sdk compile the kernel ?
<robimarko>
It should
<robimarko>
It includes the toolchain
<Ansuel>
i remember i read somewhere that it was a limitation of the sdk
<robimarko>
Hm, it says that you cannot do: Use it as a drop-in for a cross-compiling toolchain to compile the whole firmware.
<ynezz>
`git grep DEPENDS.*IN_SDK` should show the gotchas
<robimarko>
To me that is kind of ambigous, cause if it contains the toolchain why cant it be used like one?
dangole_ has quit [Ping timeout: 480 seconds]
<ynezz>
its stripped down version of buildroot so it might miss some bits as it's tailored to specific use cases, but I tend to believe, that this could be lifted
<Ansuel>
make[1]: *** No rule to make target 'target/linux/compile'. Stop.
<Ansuel>
well using the sdk to compile the kernel would be ideal
<Ansuel>
(but it can be problematic for our task IMHO for example case where we need to test bigger change with both changes to kernel and tools, using the sdk can be problematic but it's a corner case)
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
linusw_____ has quit []
robimarko has quit [Quit: Leaving]
<ynezz>
Ansuel: docker run --volume $(pwd)/target:/home/build/openwrt/target --rm -it openwrt/sdk:apm821xx-nand-snapshot make target/linux/compile
<ynezz>
`--volume $(pwd)/build_dir:/home/build/openwrt/build_dir` would be probably a good idea as well
<Ansuel>
mhhh question how we should use the sdk to test the specific commit from github in a github action ?
minimal has joined #openwrt-devel
<ynezz>
that $(pwd) is buildroot source you want to test
<ynezz>
so the source code you checkout with that GH action
<ynezz>
you don't need to use the SDK containers, you can use SDK tarballs if you want, but by using containers you're dogfooding more
<ynezz>
those containers are created from SDK tarballs
<ynezz>
so we would spot issues faster
<ynezz>
tada "time: target/linux/compile#3679.72#326.87#666.69"
<Ansuel>
really interesting!
<ynezz>
ideally we should've some separate GH action for that
<ynezz>
so we can share this better
<ynezz>
otherwise we would do a lot of copy&pasta, for example in case you would like to share the stuff in release branches etc.
<Ansuel>
the main idea was to add to the tools workflow extra code to push a ready to use container and then kernel workflow would use that to quickly test the kernel
<Ansuel>
what do you think?
<Ansuel>
(and the container is created from the buildbot container)
<ynezz>
(so in your case, you would just generate the targets dynamically)
<Ansuel>
so changes to be done are adding another make target to test build kernel (to your action)
<Ansuel>
and change our workflow to use it (using the sdk)
noltari has quit [Ping timeout: 480 seconds]
<ynezz>
I think, that for kernel it would need to be done differently then for package
<ynezz>
but the idea is still same, call simple `make ci-build-kernel` and provide it needed vars
<ynezz>
then you can use it anywhere, your local machine directly or withing docker container, any other CI
<ynezz>
what would you do now, if we would like to test both kernels? like current stable kernel, but as well next/testing kernel? you would need to share a lot of stuff anyway
<ynezz>
then how would you add it/reuse it tin 22.03 branch for example? you would either copy it manually or share it via common GH action
<Ansuel>
well having all of this would be reall useful considering with the kernel workflow we waste 20 minutes compiling tools and that is creating some problem on openwrt (if someone push kernel changes and force push multiple version)
fkaiser has joined #openwrt-devel
<ynezz>
can't we simply build test `make tools/affected-tool/compile` with SDK in the PR workflow and simply run complete build once it's pushed to master branch `on_push:` ?
<ynezz>
or maybe have full/manual build available before merging?
<Ansuel>
wait i'm not following you. We just need to speedup the kernel workflow (that try to build the kernel for each target). Why we need to buil test tools?
MaxSoniX has quit [Quit: Konversation terminated!]
<Ansuel>
mangix i also want to eat popcorn
<Mangix>
It's a figure of speech
<Ansuel>
ahahahha i know i know was curious if i could also have fun with the response
<Mangix>
Go for it
srslypascal is now known as Guest2399
srslypascal has joined #openwrt-devel
Guest2399 has quit [Ping timeout: 480 seconds]
gladiac has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
<aparcar[m]>
Ansuel: brr brr
<aparcar[m]>
oh I see the party happens over here anyway
<Ansuel>
aparcar if you want to read the discussion :D
<aparcar[m]>
yea I'll check it out in a bit
<aparcar[m]>
I'm not suuper excited about that because we need to create docker container anyway and since gitlab is cranking down free usage we'd have outdated pipelines at some point
<aparcar[m]>
not sure how updated /native-testing:latest is
<Ansuel>
mhhh from what i notice the sdk container are on docker.io
<Ansuel>
but private
<Ansuel>
the gitlab actions build the sdk from docker.io
<Ansuel>
(anyway ideally we should use github container service if we really want as we don't need to pass special secrets with github actions if we are still with the idea of github actions that update containers)
<aparcar[m]>
I'd say every commit to the master branch should build a new tools container which can then be used for the CI
<aparcar[m]>
or we do a 24h thing, I don't really care
<Ansuel>
mhhh why? can't we just limit that to changes to the tools directory?
<aparcar[m]>
uhm yea sure that's what i would have done, just like we do right noiw
<Ansuel>
one of the reason we need to fix this thing is that on multiple kernel bump/changes our github actions gets filles by 100 jobs
gladiac has quit [Quit: k thx bye]
Misanthropos has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
cbeznea has quit [Quit: Leaving.]
<mrnuke>
Applying /media/plot-maker/src/openwrt/target/linux/bcm27xx/patches-5.15/950-0590-drm-vc4-Move-HDMI-reset-to-pm_resume.patch using plaintext:
<jow>
zorun: nftables scripts are nice, the nftables cli is horrible
<jow>
whoever thought that curly braces and escaped semicolons are a good idea as command line arguments
<zorun>
:D
<jow>
also half baked concepts
<jow>
like ability to have multiple tables
<jow>
yet no way to propagate an "accept" status between them
<jow>
rendering the entire concept half useless (works for drop, but usually you have consecutive whitelisting rules, not aggregated drop ones)
<jow>
also really grave bugs in the early days, like completely broken "ifname" matching on mips
<jow>
makes one question the overall resilience of the code base
<jow>
but I guess iptables had similar issues back in the day when it replaced ipchains
<zorun>
jow: would you happen to know how "type nat" chains are supposed to work, like the dstnat one?
<jow>
can you rephrase the question?
<zorun>
I'm having an issue a dnat rule (port forward from WAN to a LAN device)
<zorun>
*with
<zorun>
packet comes in on WAN, reply goes out to WAN: "udp port 50014 unreachable"
<zorun>
in other words, this specific dnat rule doesn't work
<zorun>
when tracing with the doc above, I see that "dstnat" is never called for these packets
<jow>
did you add a corresponding accept rule?
<jow>
or is this with fw4 ?
<zorun>
it's fw4
<jow>
rthe dnat rule itself will simply match the first packet of a flow and setup a conntrack entry, the nat subsystem then takes care of rewriting all packets belonging to the flow
<zorun>
hmm, ok
<jow>
then you usually need another rule actually accepting the traffic for input/forward
<zorun>
other dnat rules work as expected
<jow>
fw4 sets up generic rules for that, which allow any packet having a conntrack state of "dnat"
<zorun>
this kind of rules? ct status dnat accept comment "!fw4: Accept port forwards"
<jow>
yes
<zorun>
they don't match, even though I have a conntrack entry