<neggles> like even if you enable it, you get... a tiny example kernel module that does a printk()
<neggles> slh: I don't think it's a good idea for rust to end up any deeper than device drivers, but IMO there are an awful lot of compelling arguments for those... plus it's going to be necessary for Apple Silicon GPU support, so it's basically inevitable...
<Ansuel_> also linus love rust...
<neggles> rust is very cool and good for device drivers, especially from a maintainer point of view
<Ansuel_> rust for mm
<Ansuel_> :D
<slh> makes the kernel lighter (on arch support) ;)
<neggles> for now - one of gcc-rs or rust-codegen-gcc will solve that problem
<Ansuel_> btw still trying to understand why bpf packages fail here
<Ansuel_> from here https://salsa.debian.org/qa/jenkins.debian.net/-/blob/master/bin/reproducible_openwrt.sh the config should be selected to correctly build llvm toolchain
<neggles> one of those two gcc rust things, I can't remember which, is specifically targeting "support
<neggles> er, "support what's supported in the kernel"
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Ansuel_ has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
<\x> whoa 807x merged
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
valku has quit [Remote host closed the connection]
valku has joined #openwrt-devel
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/63/builds/218) of `at91/sama7` completed successfully.
<jayk> where is my ath10k image?
PaulFertser has quit [Ping timeout: 480 seconds]
EqUaTe has quit [Ping timeout: 480 seconds]
valku has quit [Quit: valku]
csrf has quit [Remote host closed the connection]
csrf has joined #openwrt-devel
<Mangix> slh: no arc :)
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (98.6% images and 99.7% packages reproducible in our current test framework.)
goliath has joined #openwrt-devel
<dhewg> neggles: alright, will try, thanks for the info!
<neggles> np :)
<neggles> tbh most simple stick-type wifi antennas are basically just a slightly-carefully-chosen length of wire >.>
<dhewg> hehe
<dhewg> is there a noticably reception/quality difference when not using those simple ones?
<dhewg> as in "is it worth it?"
cbeznea has joined #openwrt-devel
<Znevna> wee fixed kernel panic
<mrkiko> woow!! IPQ807X, VDSL support for the IPQ4xx 7530... lots of nice things
robimarko has joined #openwrt-devel
<jow> anybody knows github codespace?
<jow> I thought it's a kind ofg web based IDE but apparently it can compile things
<jow> got a LuCI bug report that turned out to be broken rootfs permissions and the OPenWrt image was allegedly built using GitHub CodeSpace
<oliv3r[m]> afaik, codespaces uses a docker container in the background, which you need to have defined. Then it should be able to compile and do things. Something big like openwrt though; idk :)
<robimarko> Yes, you need to define a docker container for the repository
<robimarko> They have some default ones
danitool has joined #openwrt-devel
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
bluew has quit [Quit: Leaving]
<neggles> dhewg: not really
<neggles> it makes a big difference if you're using a directional patch antenna
<neggles> but when it comes to dumb mostly-omnidirectional antennas, there's... not a great deal of difference beyond a certain point
<robimarko> Those are probably the most untweaked antennas you can get
<neggles> yeah, i mean you'll get better performance out of the 20cm long ones than the 5cm long ones
<neggles> and sometimes the "2.4/5ghz" antenna you were sold turns out to actually be a 900mhz 1/4-wave antenna so you get massive piles of return loss
<robimarko> You know its "close enough"
EqUaTe has joined #openwrt-devel
<neggles> yeah. stick antennas basically come in "works" and "doesn't work"
<neggles> beyond that you have to either get directional, or start doing voodoo magicks with MIMO
<neggles> it's kinda funny when you see people with those 60-90cm long antennas hanging off a usb wifi dongle
bluew has joined #openwrt-devel
<robimarko> Cause, the bigger the better
<robimarko> Like TX power, I had like dozen+ questions how to fake the regulatory domain to get 30dBm TX power working
<robimarko> Cause that is the solution to every problem
<neggles> ugh
<neggles> turning up TX power often makes things *worse*!
<robimarko> Yes, cause your noise floor also goes crazy
<neggles> and it doesn't matter how loud your AP is if it can't hear your client!
<neggles> plus no current-gen wifi chipset can hit max TX power at max MCS anyway...
<robimarko> Yeah, but try explaining that
<dhewg> it's like "Router foo AX$(HUGENUMBER)", where the bigger the better
<dhewg> the sad thing is that I think it works, as in more sales
<neggles> "If I'm having trouble hearing you from across the room, will it help if I yell louder at you?"
<neggles> dhewg: oh it does, I don't really have a problem with that, I have a problem with the fact that it means everything comes set to 40mhz wide on 2.4ghz out of the box
<dhewg> I guess I don't point you to my vht 2g branch then? :P
<neggles> "if it's not set to 40mhz wide out of the box we'll get sued for false advertising because it's not capable of hitting that speed!!!!"
<robimarko> 40MHz on 2.4GHz, forget about it
<neggles> never mind that not a single person on the face of the earth has ever exceeded 200mbps on 2.4GHz outside of a test lab
<neggles> one of my friends lives in an apartment building in the city 15 floors up; the noise floor - *noise floor* - is -71dBm
<neggles> (in 2.4ghz)
<neggles> stuff coming out of the box set to 160mhz on 5GHz is just as bad - oh sure lets just go right ahead and throw away 3-6dBm of TX power for no reason
<f00b4r0> neggles: well, the root cause of the problem is here: wire/less/
* f00b4r0 hides
<neggles> i've lost count of the number of times i've "fixed" a friend's wifi problems by changing to 2.4 to 20mhz on whichever of 1/6/11 is the least fucked, and 5.8 to 40mhz wide on a DFS channel
<neggles> f00b4r0: I mean root cause is "bigger number more better", no? :P
borek has joined #openwrt-devel
<neggles> ought to be illegal. IMO if you want to market a router as being capable of X Mbps, you should be prepared to back it up with "speed achieved using X client device with Y AP settings in X conditions"
<neggles> bit late for that now though.
<f00b4r0> where "X conditions" are never met in real life scenario
<neggles> I mean even better would be to define a "reference client", or restrict it to 2x2 client devices
<neggles> this insane cambium could theoretically achieve uhhhh...
<neggles> what's the alleged maximum for 6E 1x1 in a 20mhz channel? "150mbps"?
<robimarko> Think its 143 or something like that on AX
<robimarko> But 6E is gonna be the same
<dhewg> neggles: do you have some link that explains all that? something to pass around
<robimarko> Of course only achievable on 1024-QAM with MCS-11
<f00b4r0> of course.
<neggles> I *have* managed to hit MCS11 on a 2x2 client
<neggles> ...at 10 feet distance from the AP, with both of them being the only thing for miles capable of 6GHz
<dhewg> or here's an idea: add some hints and comments to luci to help users setting it up in a sane way
<robimarko> Yeah, those are gonna be followed for sure instead of use US as reg domain and max TX power
<f00b4r0> dhewg: that'll never work. What you need is a two-button radio choice: "fast" and "insane"
<f00b4r0> and everyone will click on "insane".
<robimarko> And insane needs to actually be sane in the background
<dhewg> I like it, ship it!
<f00b4r0> robimarko: exactly ;)
<neggles> australia actually has a nicer and higher-tx-power frequency plan than the US :D
<robimarko> No, dont share it on the internet
<neggles> well the good news is, it doesn't matter worth a damn since the linux regdb ignores half the rules
<neggles> but for 5500-5700, with the exception of 5600-5650, you can run 1000mW EIRP with DFS and TPC
<f00b4r0> what I really long for tbh is an "outdoor" knob that would prevent hostapd from hoping to non-outdoor allowed DFS channels
<neggles> that's already a thing
<neggles> it's even in luci???
<f00b4r0> rephrasing: non-outdoor allowed channels during DFS changeover
<f00b4r0> is it?
<neggles> does the "installation type: indoor/outdoor" not do what it says on the box
<f00b4r0> dhewg: nice
<dhewg> there is no in/outdoor knob yet as far as uci/luci is concerned
<f00b4r0> ^
<neggles> h-uh. where's my cursed AP330 gone...
<f00b4r0> right now I'm cheating by setting the channel to "auto" and then restricting the "channels" setting. But that can only be done in uci, not luci.
<f00b4r0> i suspect a huge number of devices running openwrt outdoors are unknowingly breaking radio emission rules
<neggles> h-uh. I could've sworn there was an "indoor" / "outdoor" / "unknown" switch in here, but I guess i'm thinking of mikrotiks
<neggles> dhewg: as for a guide/explainer, i've not really come across one :/ it's not all that easy to condense into a simple little thing
<neggles> there's a lot of trial and error involved, the rules of thumb don't always apply
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 99.7% packages reproducible in our current test framework.)
<neggles> pay no attention to the -44dBm RSSI
danitool has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
<dhewg> nice, that's router to router?
<dhewg> (that's mt7921e connected to mt7921u)
<\x> robimarko: aha, kinda sucks that CN had to make do with MLO on 5GHz. https://www.acwifi.net/23566.html
Ansuel has joined #openwrt-devel
<\x> so if MLO works like this, whats stopping older things to have this enabled?
<\x> it just presents itself as two connections for reals
<\x> seems like fake MLO hey?
<robimarko> \x: Well, its kind of CN-s fault
bluew has quit [Ping timeout: 480 seconds]
<neggles> dhewg: no that's iphone 13 pro max to MT7916DAN
<neggles> because I am a crazy person who put two 3x3:2 DBDC cards into an AP from 2011
<stintel> :P
<neggles> to its credit
<neggles> it can pass 1G of TCP
<jow> neggles: which cards if I may ask?
<\x> yeah... also it seems acwifi will teardown WR30U (xiaomi's mt7981) after new years, cheap w6+aarch64 here we gooo
<jow> thinking about retiring my ath9k PCIe radios i nthe APU2 board
<jow> neggles: thanks!
<\x> neggles: are these cards 2.4 + 5/6 ? so triple band dual concurrent?
<neggles> 2.4 + one of 5 or 6
<neggles> would you like the `iw info`
<\x> iw phy / iw list termbin be nice
<neggles> sure :)
<neggles> this is a kinda old build
<dhewg> that mt7921e I mentioned earlier is an AMD RZ608 btw. Cheap, available, stable
<\x> yeah now they are
<\x> before AM5 they were kinda hard to find
<neggles> these cards work pretty well tbh. not had any trouble with them at all
<neggles> but putting two of them in the ap330 is definitely stupid
<dhewg> didn't you say more is not better earlier? :P
<dhewg> and well, there's this issue for mt7921u https://github.com/openwrt/openwrt/issues/11796 but I guess that's just some silly driver bug
<dhewg> \x: you ran into that too, right? was that also a multi mt radio setup?
<\x> i got crashes back then on intel systems
<dhewg> with no other card using the mt76 driver?
<\x> with CF-953AX, anytime a client connect to an AP made with it, it just locks up, and yep no other card
<\x> weirdly enough it is stable as hell on ipq40xx
<dhewg> huh ok so much for that theory
<dhewg> I was just gonna say that, not a single issue for months now
<dhewg> and using it daily
<\x> it also worked fine on mt7621a albeit I needed 5.15
<\x> i got crashes with 5.10
<\x> tested on newifi 3 D2, MT7621A, 4x1GbE, 7612+7603, usb 3.0
<\x> werked fine albeit yeah bad performance I say ;)
<Ansuel> i'm doing it... i'm compiling llvm toolchain.. i want to extra suffer today
<neggles> dhewg: i was being sarcastic! :P
<neggles> Ansuel: who hurt you
<robimarko> Thats gonna be self-inflicted
<Ansuel> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html trying to understand why bpf package doesn't work
<Ansuel> 3/3500 OH GOD NO
<\x> dhewg: heres when I did it https://i.imgur.com/JSg30xJ.png
<\x> client is intel AX200 but yeah seems to work well enough, this was the snapshot of that day with 5.15 (enable testing kernel)
<robimarko> Ansuel: Its gonna be something really specific to whatever the env they are running the build
<Ansuel> (from what i can see llvm toolchain are correctly built so it's strange...)
<robimarko> Do they have the build log publicly?
<Ansuel> but not useful... build log also don't display the error since V=s is not used
<robimarko> Well, that is useless as its not verbose
<Ansuel> so i hope to repro on my system but it's strange since builbot is not broken... but could be that they use llvm sdk
<\x> and ah yeah, I replaced the psu dhewg 12V 1.5A -> 12V 2.5A, else the usb wont cooperate with me but it might be a device specific thing
<robimarko> Ansuel: Its gonna be impossible to reproduce without having their exact env
<oliv3r[m]> Ansuel: can you explain me (and rosen) how this 'tools-core' thing works in (in the libdeflate PR). I took that change from his 'fix'. So is it right or wrong to have there? Does it not need to be 'added' to "something" (tools-y, tools-core)?
<neggles> u guys and ur default bootstrap themes :P https://lounge.neggl.es/uploads/2d54c3bfe312abac/image.png
<\x> i miss darkmatter theme
<neggles> (this argon theme is actually kinda broken)
<neggles> but it's also uhhh git-22.299.72136-a98e2ea
<neggles> so, not new
<neggles> Ansuel: why do they run without V=s??
<neggles> or at least with build logs enabled...
<Ansuel> they use build_log
<Ansuel> but the error is not on the log
<neggles> does it only fail on x86?
<Ansuel> nope
<Ansuel> fails on every build from that script
<neggles> I mean... ask them to add V=s? there's no other way you'll work out what the problem is
<Ansuel> still at 880/3500 with -j11 ...
<\x> neggles: classic theme enthusiast chad here https://a.uguu.se/sEOuiGuN.png
<neggles> MY EYES
mrkiko has quit [Quit: leaving]
mrkiko has joined #openwrt-devel
<\x> tfw 807x is merged 60xx in some months~~
<Ansuel> no
<\x> aaaaa
<Ansuel> :D
<\x> only gripe on this one is no reboot, i cannot reboot, i have to cut power then boot, so in the days i was setting and tuning things it was kinda yeaaaaah its something
<robimarko> Ansuel: Thing is that that is not that bad of an idea
<robimarko> Cause, it would avoid a lot of duplication
<robimarko> As ipq60xx is pretty much ipq807x lite
<\x> i guess reboot and cpu scaling above 1.5ghz but thats it, thing werks well
<robimarko> \x: Its lacking CPR
<robimarko> And those upstream OPP points are broken by default
<Ansuel> i would focus on correct upstream of ipq807x and then move to ipq60xx
<robimarko> Trust me, I am fully ignoring ipq60xx for the time being
<\x> i installed that mhz util yeah robimarko, 1.5GHz max only
<Ansuel> pc is so confused by compiling llvm that the space left is actually growing o.O
<robimarko> Though, I might send some patches that I have for DTS so they dont rot
<neggles> ipq6xxx is the new ipq4xxx
<neggles> it will haunt us for a decade
<Ansuel> ipq9564 is the new ipq807x
borek has quit [Quit: borek]
<robimarko> With Dynalink being 70 EUR its not
<robimarko> GL-Inets AX1800 toy is 100 EUR
<\x> cpu wise its equal imo, radios are worse (less streams)
<robimarko> Nope
<neggles> ipq4000 wasn't $5 and 8 cereal box tops when it was new either
<neggles> give it time
<robimarko> My point is that its not cheap enough compared to ipq807x
<robimarko> And HW-vise is way worse
<\x> also, i think theres a lack of devices
<robimarko> GL-Inet is charging 100 EUR for the bottom of the pile IPQ6000
<neggles> half of ubiquiti's current lineup
<robimarko> And they saved money on not even providing a damn programmable voltage regulator for the CPU
<\x> ill say something evil
<\x> hap ax2, hap ax3
<neggles> yeup
<robimarko> Honestly, those are too expensive for what they offer
<neggles> between ubiq and mikrotik and tp-link and edimax and <long list of firewall vendor branded APs>
<neggles> i'm not saying they're *good*
borek has joined #openwrt-devel
<robimarko> Not to mention, good luck to anybody trying to port anything to them
<neggles> nor am i saying they're worth buying
<neggles> just that plenty of things are going to show up with ipq6k in them, and The People Will Want Support Because They're In Upstream Which Means You Can Support Them Right
<neggles> </s>
<\x> if theyre cheap enough I guess, but seeing that dynalink is only 70, just go with that one
<robimarko> I am imune to those requests by now
<\x> I guess I bought early
<Ansuel> robimarko can i keep the tested by tag for the series?
Ansuel has quit [Read error: Connection reset by peer]
<robimarko> Yeah
<neggles> eh
<neggles> is ipq6k really that bad? if they're that similar to 807x it can't be *that* hard to support them, can it?
* neggles prepares his flame shield
Ansuel has joined #openwrt-devel
<\x> it does work, but you see, 807x is becoming cheap nowadays and much more supported
<neggles> and fwiw sophos at least have a long history of providing really nice GPL dumps and AIUI their soon-to-be-released APs are a mix of ipq6k and I guess ipq9k? the wifi 7 ones
<\x> if you just want something to toy with then maybe its fineeee, just dont spend too much, imo even mediatek's lower end offering is better (mt7981)
<neggles> eh; will be grabbing one or two once they land, nfr 70% off
<neggles> can probably persuade them to "loan" me one and never ask for it back
<robimarko> neggles: Its not that bad, but its not cheap enough
<robimarko> And its supportable since its derived from ipq807x with parts cut off and some modernized
<robimarko> But, just not enough time for that as well
<\x> weird in between of 50xx and 807x, hell some 50xx even come with better radios
<robimarko> Cause they are external
<\x> yeah
<\x> iirc hitech95 was here last year and was tinkering on one
<\x> good, paste is still alive https://pastebin.freepbx.org/view/bb976e37
<robimarko> I have Motorola Q14
<robimarko> And one Alfa board, but again, time
<robimarko> I got them to boot after reworking the whole GCC driver from downstream
<\x> how about 95xx, you already got hw?
<robimarko> Nope
<\x> maybe youll get the robotic one
<robimarko> I would really, really like to have dev boards instead of production HW
<robimarko> Xiaomi is like the worst one to start with
<\x> how about the msi robotic one
<\x> i really dont get why they do that lmao
<robimarko> I am trying to save money, bought enough HW myself
<robimarko> And IPQ9574 aint cheap
dangole_ has joined #openwrt-devel
<jow> Znevna: heh, again
<jow> iirc the very same thing was already disabled i nthe past
<jow> crept back up
<Znevna> same thing happens with nmbm?
<Znevna> my devices don't have bad blocks yet
<Znevna> :<
<Znevna> to test :p
<f00b4r0> so let me get this straight, in order to fix a bug that may soft-brick devices, this proposes to disable bbm, which could eventually lead to hard bricks. Interesting ;P
<Ansuel> the thing i don't understand is how this entire thing is not handled transparently...
<gch981213> Znevna: I don't understand what's going on there. I remember BMT can't be disabled with that old bootchain.
<f00b4r0> Ansuel: indeed.
<robimarko> Was that thing ever upstreamed
minimal has joined #openwrt-devel
<robimarko> Cause, MTK seems that they are not giving up on it
<gch981213> robimarko: That's impossible.
<dhewg> iirc mainline has an incompatible solution?
<gch981213> ubi does what MTK wants in a far better way.
<robimarko> Well, that is just fantastic
<robimarko> So its gonna be an issue forever
<gch981213> The BMT/NMBM is used because the NAND flash programmer used in mass-production usually can only write a single image. When it encounters a bad block, it skips that block and shifts the content back one block.
<robimarko> Well, then the question is how the hell does every other vendor not use it and still flashes NAND-s just fine?
<gch981213> so BMT/NMBM is used to shift everything forward.
<gch981213> on raw mtd device.
<gch981213> UBI isn't affected by this behavior.
<gch981213> UBI can handle the skipped bad blocks. If they can put factory into UBI and add some logic to handle skipped bad blocks in preloader, they shouldn't need BMT.
<gch981213> However, back in the mt7622 days they want JFFS2 on nand...
<gch981213> robimarko: I don't know what other router SoC vendors' solution to this. Phone SoCs don't use NAND programmer in mass production, they use recovery mode in bootrom instead, and several images are written to the correct offsets separatedly.
<gch981213> so a skipped bad block in one mtd partition won't cause contents in other partitions to shift.
<robimarko> Well, that is my point
<robimarko> A lot of BCM and QCA routers use NAND and only NAND and they are all using UBI just fine even from factroy
<gch981213> I just asked someone. QCA doesn't provide a solution to this problem at all.
<Znevna> hmm
<gch981213> My assumption: Since they use UBI for main data area and the odds that a factory bad block appears at the front boot chain area is low, vendors could probably throw away nand chips with bad blocks at the front.
<robimarko> Well, that is great for us
<Znevna> think I can mark a block as bad and see what happens
<gch981213> Znevna: I remember mark-bad triggers a block replacement in nbd's implementation?
valku has joined #openwrt-devel
<Znevna> I don't know
<gch981213> Oh. you mean in u-boot.
<Znevna> yes
<gch981213> Don't :)
<gch981213> nand command operates on nand, not through NMBM
<Znevna> right, i was in the wrong submenu https://paste.debian.net/plainh/95ea0de0
<gch981213> You can mark-bad in OpenWrt to trigger a block replacement, and dump in u-boot to check if it sees the block replacement result.
owrt-snap-builds has quit [Remote host closed the connection]
owrt-snap-builds has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
<Znevna> I'd have to boot openwrt with nmbm enabled
<Znevna> but how will that reflect a real world scenario? :P
<Znevna> I don't have a built image with nmbm I think, since I don't know the proper values to put there for nmbm
Ansuel has quit [Read error: Connection reset by peer]
<gch981213> Znevna: The problem in #11814 according to the author is that xiaomi u-boot doesn't use BMT while OpenWrt enables it.
<Znevna> oooooh
Slimey has joined #openwrt-devel
<Znevna> so I'm safe to enable it then
<Znevna> still don't know what I sould enter for reserved blocks tho
<gch981213> Znevna: I also don't know :( Maybe nbd can help?
Ansuel has joined #openwrt-devel
<Ansuel> love the reason thx ynezz
<robimarko> Hehe, I saw the buildbot disconnect and hoped it would be that
<f00b4r0> ynezz: any progress with testing? :)
soxrok2212 has quit [Quit: Who ate my gummy worms?]
<Mangix> oliv3r[m]: tools-core build before others.
<oliv3r[m]> so then it makes sense, to build libdeflate as a tools-core as it's needed by others (e.g. even cmake needs libdeflate (gzip really)
<Mangix> Sure, but it makes sense when it's actually used.
<Ansuel> i was checking what was so big in my wsl installation
<Ansuel> 105G /home/ansuel/openwrt
<Ansuel> 69G ./build_dir
<Znevna> :P
<Ansuel> 18G ./staging_dir
<Ansuel> for once NOT NICE
<oliv3r[m]> yeah, i'm onyl doing the realtek target and it's costing me huge amounts :p
<dhewg> which is why I symlink those to tmpfs
soxrok2212 has joined #openwrt-devel
<gch981213> Mine is at 113G with 3 targets built.
<robimarko> Got the reproducible guys to build with V=s, they are gonna kickoff x86 build
<Ansuel> nice you contacted them on irc?
<Ansuel> 6.4G staging_dir 43G build_dir
<robimarko> Yeah, seemed easiest to do
<robimarko> You are a brave man building LLVM
<Ansuel> (i removed all the old toolchain lol)
<Ansuel> stopped doing that on 4th try... i discovered if the thing doesn't stop everything is restarted from scratch
<Ansuel> like wtf?
<robimarko> Did you use CONFIG_BUILDBOT?
<Ansuel> yes?
<robimarko> Well, that is why its rebuilding everythign
<robimarko> Cause:
<robimarko> │ This option changes several defaults to be more suitable for │
<robimarko> │ automatic builds. This includes the following changes: │
<robimarko> │ - Deleting build directories after compiling (to save space) │
<robimarko> │ - Enabling per-device rootfs support
goliath has quit [Quit: SIGSEGV]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<owrt-snap-builds> Build [#767](https://buildbot.openwrt.org/master/images/#builders/25/builds/767) of `rockchip/armv8` failed.
<ynezz> f00b4r0: not yet, sorry
<Ansuel> guys am i wrong or they removed issue and pull request number?
<Ansuel> ok nope just me
<Ansuel> they are back
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<Ansuel> well it seems buildbot almost finished
<Ansuel> aaand he failed... SAD
<Ansuel> ERROR: target/imagebuilder failed to build.
goliath has joined #openwrt-devel
bluew has joined #openwrt-devel
<robimarko> Ugh, error is weird
<ynezz> Ansuel: indeed, it's misbehaving build worker, should be fixed soon
<ynezz> its OOM killer, there are 2 build workers running from the same host
<robimarko> Ok, cause it said Killed and then tar failed
<ynezz> its a docker container, so the OOM from the host is not visible
<hurricos> stintel: The second BDI2000 is headed with hmartin
<hurricos> It'll be in the EU by the end of the month as he returns. Let me know if you'd like to share a mailing address, or you can reach out to him for one
srslypascal is now known as Guest1631
srslypascal has joined #openwrt-devel
<robimarko> ynezz: ok, thanks
Ansuel has quit [Ping timeout: 480 seconds]
Guest1631 has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
<Ansuel> ynezz probably caused by the forced run ?
<robimarko> Ansuel: Can that libdeflate PR be merged?
<Ansuel> i'm confused
<Ansuel> so my review were not missing but we have 2 pr doing the same change...
<Ansuel> ok this needs to be merged first
<robimarko> First it was oliver that did a PR, then mangix fixed it up
<robimarko> Then I think it got renamed, so it looks like 2 doing the same
<ynezz> Ansuel: no, probably server admin (or server reboot) has started that 2nd build worker which was disabled previously due to exactly those OOM issues
soxrok2212 has quit [Quit: Who ate my gummy worms?]
<Znevna> the numbers of those PRs say otherwise ;P
soxrok2212 has joined #openwrt-devel
<Znevna> what' will I ever need 32GB of RAM for, that's too much. Me starting an extra VM today > nope.
soxrok2212 has quit [Quit: Who ate my gummy worms?]
<owrt-snap-builds> Build [#760](https://buildbot.openwrt.org/master/images/#builders/35/builds/760) of `mvebu/cortexa72` failed.
soxrok2212 has joined #openwrt-devel
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
danitool has quit [Ping timeout: 480 seconds]
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
Ansuel has joined #openwrt-devel
cbeznea1 has quit [Quit: Leaving.]
Borromini has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<jayk> d'oh, why is bison-3.8.2 (latest) bad..
<jayk> checking for bison 2.4 or newer... 3.8.2, bad
<jow> jayk: likely a broken detection script
Borromini has quit [Ping timeout: 480 seconds]
<jayk> jow: ah
svanheule has joined #openwrt-devel
Borromini has joined #openwrt-devel
svanheule has quit [Quit: svanheule]
svanheule has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<Znevna> robimarko: in RouterOS / RB5009 we can see on which physical port a MAC is seen, can we do that in OpenWrt ?
<Znevna> actual question would be another one though, RouterOS queries the switch for that data and it uses a lot of CPU, just curious if that was the case in OpenWrt too x.x
<dangole_> starting off a clean build directory today, now util-linux (built because of fstools build-depending on it) tries to link against /lib/libncursesw.so (ie. the host library) which can't work for obvious reasons. has anyone else seen this and/or any idea what may be happening in the meson/ninja rabbit hole?
<stintel> ip neigh or bridge fdb
<stintel> Znevna: ^
<Znevna> thanks ^^
<stintel> yw
<Ansuel> dangole_ fun thing... i would first start from the config log
<dangole_> Ansuel: if it was autotools and there'd hence be config.log, then i'd very well know how to help myself
<dangole_> Ansuel: unfortunately it's "a modern build system", which implies hiding all it's internal workings somehow, hence there aren't any log files or even contant non-self-replacing console output which could be used to investigate this kind of issue
<dhewg> worked for me yesterday, and I'm always rebuilding everything clean since tmpfs
<dhewg> was some used library updated today?
<dangole_> dhweg: i don't think so. could be that it's somehow related to being the first time i build anything for risc-v...
<dangole_> dhewg: i'm trying to port for StarFive JH7110 SoC on top of that...
<dhewg> oh, hm
<dhewg> iirc there's meson.mk which maps archs to its internal name
<dhewg> maybe it need risv-something?
<dangole_> dhewg: oh interesting, that can be.
<dangole_> dhewg: didn't know that meson needs internal arch names...
<dhewg> not everytime, but they differ sometimes
<dangole_> dhewg: ok, i try to find the list of meson-allowed archs then first of all...
<dangole_> dhewg: ah ok, so CONFIG_ARCH="riscv64" should just be fine then
<dhewg> yeah, look like it
<dhewg> +s
bluew has joined #openwrt-devel
<dangole_> dhewg: hm, reverting to autotools-based util-linux (fortunately the change is not too far back) fixes it...
<dhewg> hehe, well ok dunno
<dhewg> does the ncurses pkg-info file look ok?
<owrt-snap-builds> Build [#756](https://buildbot.openwrt.org/master/images/#builders/31/builds/756) of `layerscape/armv8_64b` failed.
<Ansuel> robimarko btw libdeflate thing merged
<robimarko> Znevna: No idea
<robimarko> Ansuel: Great
<robimarko> Znevna: Its gonna eat some CPU time, as you are fetching data over MDIO
<robimarko> Depends on the frequency
<Znevna> spikes ~20% on a core locked to 1.4
<Znevna> anyway as long as you're not looking at anything that reads that data it's fine :P
goliath has joined #openwrt-devel
<robimarko> Well, that is quite a lot
<robimarko> But I am gonna guess they are refreshing agressively
<Znevna> probably
<robimarko> MDIO is a quite slow bus, especially if there are multiple devices so there is a lot of waiting under lock
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (96.2% images and 99.7% packages reproducible in our current test framework.)
robimarko has quit [Quit: Leaving]
cmonroe_ has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
<Borromini> Znevna: on RouterOS you mean, or are those spikes on OpenWrt as well?
<dangole_> dhewg: ncursesw.pc looks innocent, no idea where that seemingly hard-coded path makes it into LDFLAGS when using meson to build util-linux...
<Ansuel> did we checked if the culprit is util-linux itself that is hardcoding stuff?
<owrt-snap-builds> Build [#124](https://buildbot.openwrt.org/master/images/#builders/80/builds/124) of `mediatek/filogic` failed.
<Ansuel> well it seems we have a builder that is going oom everytime
<Znevna> Borromini: on RouterOS, I didn't put OpenWrt on it.
<Borromini> ok
Borromini has quit [Quit: Lost terminal]
<Mangix> robimarko: something like that yeah.
soxrok2212 has quit [Read error: Connection reset by peer]
soxrok2212 has joined #openwrt-devel
<neggles> \x: ye the MT7981 stuff is definitely much more interesting
<neggles> hurricos: what are you doing with BDI2000s :P
robimarko has joined #openwrt-devel
<neggles> Znevna: the routerOS implementation does a whole shitload of individual MDIO transactions instead of batching/queueing them up
<neggles> their assumption is that you'll only be pulling that data more than a few times a minute for diagnostic/debug
<robimarko> Ansuel: Yeah, that one is getting killed for each build
<neggles> it's also a bit dumb because they *could* be querying it via 802.3BR L2 packets but w/e
<neggles> 802.1br*
<neggles> also hey! hey mikrotik! *I see that M.2 slot you put on there*
<robimarko> Its just a matter of time before the LTE or WLAN version as PoE one as predicted came out
<neggles> it.s a 2280 slot...
<neggles> there's also an FFC connector marked "PCIe, USB" though
<neggles> and a footprint for a u-blox GPS chip
<robimarko> They like to keep their options open
<neggles> if they did one with a 2280 SSD slot and 4-8GB of RAM that would be *awesome* for running little containers on
<robimarko> They aint gonna give you that in this price range
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
<neggles> eh, I don't mind if it's $100 more
<neggles> oooooooooooooOOOOOOOO https://www.gl-inet.com/products/gl-x3000/
soxrok2212 has quit [Read error: Connection reset by peer]
<neggles> only 512MB of RAM? *sigh*
danitool has quit [Read error: Connection reset by peer]
soxrok2212 has joined #openwrt-devel
danitool has joined #openwrt-devel