torv has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
minimal has quit [Quit: Leaving]
jennie has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
<jennie> hello
Tapper has quit [Ping timeout: 480 seconds]
swalker has quit [Ping timeout: 480 seconds]
swalker has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
swalker has quit [Remote host closed the connection]
swalker has joined #openwrt-devel
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer1 is now known as hanetzer
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
PtitGNU has quit [Quit: Quassel terminated!]
PtitGNU has joined #openwrt-devel
cmonroe_ has joined #openwrt-devel
<Mangix> jennie: hello
<jennie> Mangix I am having hard time, can you please help me out?
danitool has quit [Ping timeout: 480 seconds]
jennie has quit [Quit: Going offline, see ya! (www.adiirc.com)]
gch981213 has quit [Quit: Konversation terminated!]
valku has quit [Quit: valku]
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (98.6% images and 99.5% packages reproducible in our current test framework.)
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
chuck48 has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
gch981213 has joined #openwrt-devel
<oliv3r[m]> hauke: next oddity I discoved, when I use generic mips kernel, and LZMA compression in the target Makefiles, no boot/output. but only changing it to (libdeflate-)gzip, it's fine. I'll try a few other compression algs but this is beyond weird ...
goliath has joined #openwrt-devel
cbeznea has joined #openwrt-devel
robimarko has joined #openwrt-devel
<stintel> f00b4r0: robimarko: m400/m500 is x86 fyi and so is m440
<f00b4r0> ah!
<robimarko> stintel: ah, not interesting then
<dwfreed> I mean, interesting as in powerful
<f00b4r0> robimarko: maybe the hardware from #10941 would be more appealing to you then ;-D
<dwfreed> but not interesting as in a challenge to port
<robimarko> Well, that looks more interesting
<f00b4r0> wait until you see the price tag xD
<robimarko> And then they say its never been on the market
<robimarko> Ok, nope
<f00b4r0> robimarko: that's a devboard version, but there are commercial devices
<stintel> can order on mouser, 52wk lead time, almost 5k EUR :D
<f00b4r0> ^
<f00b4r0> :}
<robimarko> Almost affordable
<f00b4r0> i wonder if that would be one of the most (if not *the* most) expensive devices OpenWrt supports, assuming that PR gets in ;)
<robimarko> My SparX-5 reference would be close
<robimarko> Only 4.4k USD
<f00b4r0> cheap :D
<robimarko> When you are not the one paying then its great
<f00b4r0> hehe
borek has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<karlp> aiyion: have you seen the "partname: Ignore root=PARTUUID" patch?
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 99.6% packages reproducible in our current test framework.)
guidosarducci has joined #openwrt-devel
chuck4888 has joined #openwrt-devel
chuck48 has quit [Ping timeout: 480 seconds]
chuck48 has joined #openwrt-devel
chuck4888 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<Znevna> so no clues about that nvmem error huh
<jayk> looks like it doesnt exist
<jayk> did you display all env vars
<Znevna> m?
<jayk> maybe not supported for your rev or router
<jayk> or is obsolete
<Znevna> you're not talking about this, are you? https://paste.debian.net/plainh/68f1da2b
<ynezz> karlp: if you've some time, it would be nice if you could test that patch on sunxi, I was wondering if it might break such targets as well
<karlp> ynezz: I barely understand it's issue, but it looks like it's related to what aiyon was working on :)
<karlp> but yeah, I'm bringing up my boards again, moving some stuff from my desktop to the sunxi board now.
Tapper has joined #openwrt-devel
guidosarducci has quit [Ping timeout: 480 seconds]
guidosarducci has joined #openwrt-devel
<Znevna> yay
<stintel> but looks like it doesn't compile, probably made a booboo
<Znevna> yeah I've ruined my build system trying to pinpoint the commit that broke nvmem-cells
<Znevna> have something to do for work, will try again later
<stintel> anyway, pretty sure I found the problem, I've also created an issue for it, and pinged Daniel (who introduced the bug)
<robimarko> Basically, for the layouts they introduced the nvmem-cells
<robimarko> As you can now provide more than one MAC for example
Ansuel has joined #openwrt-devel
<robimarko> Hm, however that is not yet backported to OpenWrt
<Ansuel> helo
<robimarko> Introduced the OF support for nvmem-cell-cells
<robimarko> Ansuel: Hello, weird to see you this "early"
<Ansuel> what is the current topic today? :D
<robimarko> You know, the usual broken stuff
<Znevna> thing is it just might be a warning? since the MAC is set properly it seems x.x
<stintel> Znevna: https://git.openwrt.org/b055c62ca7791bd7d989fd68edff0ccc63e3d624 fixed version, no more panic when reading /sys/kernel/debug/ppe0/entries
<Znevna> nice
<Znevna> can we haz 5.15 for rampis naw
<stintel> not yet
<Znevna> for ramips too
<robimarko> Znevna: Its a false warning
<stintel> this is in my staging tree awaiting feedback from Daniel
<Znevna> and then
* Znevna hides
<Znevna> robimarko: thought so
<Znevna> would be nice to fix it tho :P
<Znevna> warnings scare people
<robimarko> Fun thing is that the upstream commit to make it optional is backported already
<Znevna> but why does it complain?
<robimarko> Still looking for it
<oliv3r[m]> is there an 'environment'-ish variable available in Kconfig files to determine if we are on a 32 or 64bit system? (and le vs be as well?) so that I could do 'select SYS_SUPPORTS_64BIT_KERNEL if ARCH64'?
<oliv3r[m]> We set ARCH:=mips in our top makefile, so there's that
<robimarko> depends on CPU_SUPPORTS_64BIT_KERNEL && SYS_SUPPORTS_64BIT_KERNEL
<robimarko> Arch has to declare this and then 64BIT will be available
<robimarko> Me and you both
<oliv3r[m]> though I think, my problem might actually be: https://elixir.bootlin.com/linux/latest/source/arch/mips/Kconfig#L160
<oliv3r[m]> I'm testing still, so give me a few compiles :S (e.g. an hour or two :p
<robimarko> Yes, you are on the right track
<oliv3r[m]> what track is that? :p
<robimarko> CPU_SUPPORTS_64BIT_KERNEL will get selected based of the MIPS release that you select
floof58 is now known as Guest959
<oliv3r[m]> so while SYS_SUPPORTS_64BIT_KERNEL and SYS_SUPPORTS_BIG_ENDIAN are set, there is still some detection in place?
floof58 has joined #openwrt-devel
<robimarko> Yes
Guest959 has quit [Ping timeout: 480 seconds]
<robimarko> CPU needs to be 64 bit as well
<oliv3r[m]> let me ask it differently, which CPU's is MIPS_GENERIC_KERNEL targeted? generic enough for nearly all MIPS cores?
<robimarko> So you need SYS_HAS_CPU_MIPS64_R1 or other MIPS64 flavors set
<oliv3r[m]> yeah but MIPS_GENERIC_KERNEL basically sets them all
<oliv3r[m]> I'm contamplating how generic this board-agnostic generic mips kernel is
<oliv3r[m]> generic if you have MIPS64_R6 :p
<oliv3r[m]> anyway, let me run my tests first, and then I'll tell you if lzma + R6 is causing my crashes
<robimarko> There has to be a way to set the exact CPU in KConfig as well
<oliv3r[m]> well if you go towrds 1 kernel to rule them all; like arm is trying to do; it should be possible with mips too?
<oliv3r[m]> just have a fat kernel that you can run anywhere (as long as you have a proper devicetree)
<oliv3r[m]> hmm, removed R6 and still crashes :) so that's good i suppose
<aiyion> karlp: yes, I've just not had enough freetime to build and test it yet. But it reads like Christian already brought up devices like ours.
<robimarko> Znevna: I will test on linux-next
<robimarko> Cause, I have a feeling that the generic OF part was backported but NVMEM code for 6.3 was not
<dhewg> nbd: mt76 has USB_DEVICE(0x7392, 0xb711) in mt76x0/usb.c and mt76x2/usb.c too, is that intentionally?
<robimarko> Znevna: Ok, so the stupid warning exists in next as well
<Znevna> nice
<mrkiko> For forum post https://forum.openwrt.org/t/tl-mr6400-v4-qmi-not-working/147888 - my answer would be that ModemManager is needed; even to me uqmi didn't work but MM did. Installing MM on a device with 8MB flash is not ideal admittedly, but so far that was what I did. the device works then.
<robimarko> Does it fit?
<Ansuel> https://github.com/Ansuel/openwrt/actions/runs/3883814018 crazy idea run everything as alpine image base
<Ansuel> curious if it will work
<robimarko> Any reason for that other than Alpine uses musl?
<stintel> wigyori: hey
<Ansuel> robimarko main task is reduce container size
<Ansuel> but i'm curious if there are other tools broken by musl glibc
<robimarko> Thats a good idea
<Ansuel> libc*
<rmilecki> Znevna: i have mwalle debugging that issue this very moment
<ldir> master is throwing dep check errors under macos Build dependency: Missing argp.h Please install the argp-standalone package if musl libc & Build dependency: Missing obstack.h Please install the musl-obstack-dev package if musl libc. - that's new!
<ldir> and the make FORCE=1 doesn't help
<Ansuel> ldir it should be fixed
<Ansuel> with latest commit
<robimarko> rmilecki: Like Miquel pointed out, basically that cell is gonna need to be counted as 0 by default
<stintel> wigyori: can you ping me when you did your sifiveu rebase? I'd like to see this land before we branch for the next release. I can test on hifive unmatched and give you a tested-by
<rmilecki> robimarko: it is...
<ldir> Ansuel: thanks :-)
<rmilecki> or - it should be ;)
<Ansuel> ldir for context i'm checking alpine support and i notice these thing were missing but bsd system have specific fixup for these missing libs
<robimarko> rmilecki: AFAIK its currently not
<rmilecki> robimarko: let me rephrase that - it should be by looking at existing code but it may be broken
<robimarko> rmilecki: ok, I get you now
<robimarko> It was also supposed to be fully optional but that is not working as intented
<rmilecki> correct
<oliv3r[m]> hauke: So for me, when I enable SWAP_IO_SPACE https://elixir.bootlin.com/linux/latest/source/arch/mips/Kconfig#L157 in combination with LZMA, the board doesn't even show boot info. Without LZMA but gzip it boots, but stops also relatively quickly also actually (cpu time source setup something)
dangole has joined #openwrt-devel
<Namidairo> my condolences to whomever has to review your 807x PR
<Ansuel> the only concern is the qsdk makefile
<Ansuel> but rest of the commit is clean
<Ansuel> we polished it for month
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<robimarko> SSDK and NSS-DP is pretty much as clean as it can be
<Namidairo> is that pcie 1x1 on the ax9000 working
<robimarko> Yeah
<robimarko> Its just QCA9889
<Namidairo> yeah it's just that I remember pcie wasn't coming up not too long ago
<robimarko> That was a while ago
<robimarko> Got that tracked down to trying to read/write DBI space
<robimarko> Before PCIe PHY was powered on
<robimarko> That has been upstreamed and even backported to all of the stable releases
<Ansuel> 6.1 is still not in LTS
<Namidairo> won't all these inbox/toh wiki links break later
<robimarko> No idea what are they waiting
<Ansuel> greg is heving some fun with OEM complaining about rust being a breaking change for some reason...
<robimarko> Namidairo: What do you mean?
<Namidairo> don't the pages get moved out of inbox later
<robimarko> Namidairo: sorry, but you are gonna have to draw a picture for me
<robimarko> No idea what you mean
<Namidairo> all those device pages linked in the commit messages for the devices
<robimarko> Honestly, no experience with that
<robimarko> But I put the install instructions in the commit directly
<f00b4r0> robimarko: i'm anticipating one problem with nvmem cells layouts for mikrotik devices: for devices which have both old and new style LZOR packging (where you can have a single wlan_data or 2 wlan_data files): I don't think this can be expressed in a dt-compatible way
<robimarko> f00b4r0: oh yeah
<f00b4r0> so I'm afraid we're screwed ;P
<Namidairo> a few of them have prerequisite steps for gaining access to terminals linking to wiki pages
<robimarko> Namidairo: I know, but SSH jailbreaks change all of the time
<robimarko> No way they can fit in the commit itself as well
<Namidairo> I guess ask tmomas or whomever was keeping the wiki clean
<mrkiko> robimarko: is serial still mandatory to install OpenWRt on the AX9000 ? Guess yes, but I'm not updated on the matter
<robimarko> mrkiko: No
<robimarko> You can install directly from stock FW after getting root without UART
<mrkiko> robimarko: thanks
<mrkiko> robimarko: was just curious about that device, even tough I guess I am better in waiting for wifi 7 directly ...
<robimarko> mrkiko: QCA just volleyed the bare minimum clock/pinctrl for IPQ9574
<mrkiko> robimarko: still looks interesting hardware to try
<robimarko> But HW is unobtanium
<Namidairo> i feel like you may be waiting a while, even though the mt7996 just got prelim EHT patches in mailing list
<mrkiko> robimarko: don'tknow what unobtanium means, but doesn't look like a good thing :D
<Namidairo> that and yeah you ain't getting the hardware right now unless you're sampling for a huge run
<robimarko> mrkiko: nyou cant purchase it
<mrkiko> robimarko: Namidairo: thanks
<robimarko> Xiaomi and TP-Link have techincally released BE models, but you cant buy them
<mrkiko> I'll wait. As you probably already know, having a device I can recover without serial is very valuable to me :D
<robimarko> All of the Xiaomi devices have that
<robimarko> They have baked-in TFTP recovery in the bootloader
<robimarko> However, you can only flash stock FW as they are checking the signature
<mrkiko> robimarko: the problem is signed images if I remember correctly... so the AX9000 might load a TFTP image but I need to use the signed OEM and jailbreak again from there
<Namidairo> they're just horribly inconsistent about what filename you require
<robimarko> Yeah
<Namidairo> sometimes it's ip address in hex, sometimes it's model name
<robimarko> Its easy to see what its requesting, but I hate that they want signed images
<mrkiko> robimarko: infact, fully agree. Even because obtaining the file for a stock firmware who is jailbreakable isn't always as easy as one might think, and trial and error process is not a thing here ...
<Namidairo> they're kind of dead-ended as well because they still don't have regulatory approval for 6ghz in their main market
<robimarko> mrkiko: Its actually easy to get whatever version of FW you want
<mrkiko> robimarko: happy to know that
<robimarko> API links for every model have been figured out and they provide nice JSON with all of the versions along with direct links
minimal has joined #openwrt-devel
<Namidairo> yeah they don't really clean up their cdn luckily
<mrkiko> After all, once you have one such file stored in a safe place, you're good to go
<robimarko> It is getting damn hard to exploit them with every new model though
<robimarko> I only have them as they are cheap so quite popular
<Namidairo> huh, that's a QCN6274 in their new product.
<ukleinek> jow: now I came around to build and test your suggestion, it works great and so I updated the PR (https://github.com/openwrt/luci/pull/6155)
<Namidairo> but the front end module still has no 6ghz so that's still off the table
<robimarko> Namidairo: They usually sell a global version as well
<robimarko> After a while
<robimarko> Only 699 USD
<mrkiko> robimarko: would be nice to know on which SOC it's based
<robimarko> I am just trying to figure out the FCC ID
<Namidairo> who wants to be the one to start an x server and doom on there
<robimarko> But my money would be on IPQ9574
<Namidairo> marketing sheet for that lists "Openwrt" as a supported os
<robimarko> Naturally
<robimarko> They like to keep breaking the trademark
kenny has quit [Ping timeout: 480 seconds]
<Namidairo> it's fine, we didn't capitalise the W
<Ansuel> robimarko ohh you discovered that shit thing....
<Ansuel> on the front they are all controllable led
<Ansuel> scared of the hacks they did to implement that
<f00b4r0> 700 bucks for a router. What has the world come to 🤦‍♂️
<f00b4r0> home router*
<Ansuel> well that thins is a server
<wigyori> stintel: yep, should be tonight or tomorrow
<Ansuel> they just limit the port LOL
<robimarko> f00b4r0: They have the "mesh" Deco BE95 pair for only 1199 USD
<Ansuel> 2 x 10g
<Ansuel> 4 x 2.5 g
<Ansuel> LOL
<f00b4r0> robimarko: nice business they have. If it sells.
<robimarko> They are not even avaialable yet
<Ansuel> if it's for real ipq9574
<Ansuel> that soc is a powerhouse
<robimarko> Port specs scream IPQ9574
<Namidairo> do these even have a gpu in their design
<robimarko> Nah
<Ansuel> but it does have a touchscreen LOL
<f00b4r0> you mean it doesn't run Doom? Disappointment. ;P
<robimarko> Well, for 700 USD it better do
<f00b4r0> right.
<Namidairo> i mean if we were going to run doom it was going to be straight framebuffer shenanigans anyway
<Ansuel> actually that thing should be able to run 2 doom
<Ansuel> one in the led screen and the other on the touchscreen
<f00b4r0> lol
<Namidairo> I'm just concerned about the actual production UI being a giant slowpoke
<robimarko> It TP-Link, so I dont expect anythign
<Ansuel> considering it's home router
<Ansuel> probably it's limited to the hell
<Ansuel> like 3 button and be done with it
<Namidairo> scrolls right on the touchscreen, throughput drops 50%?
<stintel> wigyori: thanks
<f00b4r0> stintel: openwrt on VisionFive2 happening? ;)
<f00b4r0> it seems they're already changing the specs btw
<f00b4r0> looks like this'll be yet another gazillion variant platform.
<Namidairo> again?
<f00b4r0> Namidairo: got a KS update saying they're switching to 4xUSB3
<f00b4r0> if i read that right.
kenny has joined #openwrt-devel
<robimarko> Damn, QCA went all out on IPQ9574
<robimarko> One fully built-in 4x4/40 2.4GHz AX radio
<robimarko> And 4x PCIe interfaces for BE stuff
<wigyori> f00b4r0: it will happen, yes
<f00b4r0> nice! I'm happy to do testing if that can help
<wigyori> it's a bit farther than tomorrow, but thanks :)
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (11.1% images and 99.6% packages reproducible in our current test framework.)
<mrkiko> wigyori: hi!!!!!! Thanks again for all your help and kindness!!
<mrkiko> wigyori: it took a while for me to map your nick to you :D
<Namidairo> have to beat all those mt7988 devices somehow.
<wigyori> mrkiko: hi - sure thing, no worries :)
<mrkiko> robimarko: wow, looks very ninteresting. Still, wonder what's the perspective of supporting it will be if trend continues as is - I mean, QCA gives out very little info and code, or am I wrong?
<mrkiko> wigyori: :)
<robimarko> mrkiko: QCA gives 0 docs, but all of the code that touches GPLv2 is released
<mrkiko> Namidairo: :)
<robimarko> The pain points like always will be wired networking
<Namidairo> they give out code, it's just of questionable quality and tested against magical non-public firmware blob
<robimarko> Quality is your tipical vendor crap
<mrkiko> robimarko: yes, after having looked at the work that Ansuel did on qca8k ... I think I understand little more. I was happy to see that happening...
<robimarko> qca8k is easy
<robimarko> Datasheet leaked ages ago
<robimarko> But then, datasheet was wrong in number of places
<mrkiko> robimarko: but even then the hardware behaviour wasn't consistent with docs if I understood correctly
<robimarko> Yeah, the tag info about reading MIB-s via ethernet packets was completely wrong
<robimarko> And plenty other things
<Namidairo> you should see the dumpster fire in their bluetooth chipsets
<mrkiko> If the GL-AP1300 dsa conversion is merged, all the IPQ401x devices I have should be DSA-compatible :D
<Namidairo> they had to retract some features after the fact "oops we couldn't support that after all"
<robimarko> Namidairo: I hope to live and see a vendor SDK that isnt dumpster fire
<robimarko> But some things like SSDK deserved to be instantly burned
<Namidairo> eww mediatek are shoving 11ax-only variants under the same model name
<robimarko> You mean Filogic or?
<Namidairo> just skimming through this mt7996 patch on linux-wireless
<robimarko> Oh you mean using the MT7996 name for completely different features
<Namidairo> call it something else lol
<Namidairo> hehe do { //blah } while(0)
<robimarko> Its gonna be interesting to see how long will it take to be able to get them
<Namidairo> given the spec does not finalise until the end of next year and all sure
<robimarko> Namidairo: That is why I hope all of this stuff wont end up being non certifiable like AX was at the start
<mrkiko> nick[m]12: ping
<nick[m]12> mrkiko: pong
<mrkiko> nick[m]12: sorry, didn't notice you wrote... regarding PR #10909
<mrkiko> nick[m]12: do you have any device to test?
<mrkiko> nick[m]12: I can confirm it works on my AP1300 (so in case feel free to add my tested-by tag), but was wondering about MAC adresses info..
<nick[m]12> mrkiko: no I sadly have no device to test. I just did it for bluewavenet months ago.
<rmilecki> Znevna: are you able to apply a kernel patch and test nvmem? https://lore.kernel.org/all/03db256d8cb68344d9e42ae8ee694ec7@walle.cc/
<nick[m]12> mrkiko: so I can not test what mac adresses are correct. can you give me your chnages?
<mrkiko> nick[m]12: I did not changes, just applied the PR and flashed the device with u-boot's help. All works well, the only strange thing is - lan and wan have the same mac addr
valku has joined #openwrt-devel
<mrkiko> nick[m]12: and i'm pretty confident the led thing should be OK by now
<nick[m]12> mrkiko: can you compare the mac addresses against the stock firmware?
<mrkiko> nick[m]12: not easily...
<mrkiko> nick[m]12: if I have the chance I might try against the pre-dsa openwrt version... and let you know
<nick[m]12> mrkiko: that would be nice
<mrkiko> nick[m]12: by "it doesn't work" you mean - it gives you the"resourcebusy" error?
<Znevna> rmilecki: yes, I can try
cmonroe_ has quit [Ping timeout: 480 seconds]
<Znevna> hope I got the patch right
<Znevna> yeah i didn't
<Znevna> attempt #2
chuck48 has quit [Remote host closed the connection]
<robimarko> You are gonna need to manually fixup the patch
<f00b4r0> I love it how homebrew thinks they know better than their users. "We won't add sshpass because it makes it too easy for novice SSH users to ruin SSH's security"
<f00b4r0> do I regret using that garbage
<PaulFertser> Gentoo prefix runs on macOS too.
<robimarko> rmilecki: That patch fixes things
<robimarko> Warning is gone
<f00b4r0> PaulFertser: I normally rely on MacPorts, which is much saner in every aspect. Unfortunately that's not what I have on this machine (I installed homebrew at a time I didn't know better). Luckily sshpass isn't too hard to build by hand
goliath has quit [Quit: SIGSEGV]
cmonroe has joined #openwrt-devel
<Ansuel> jow wonder if you can give some feedback about the luci pr and after i merge all the iwinfo and rpcd fixup wonder if you can delete the additional extra branch (those repo have policy to reject force push and delete so I had to create a new branch)
<mrkiko> f00b4r0: naive question regarding MAC OS - what if you break the system somehow or you simply have too many things around installed iva 2make install" and so on, so that no package manager knows about them... is there an easy way to "clean" the OS without re-configuring / re-installing everything?
<f00b4r0> mrkiko: there are several options depending on how "clean" you want the system to be
<f00b4r0> you could rm -rf /usr/local and start over, to boot. That's quick and dirty, but it works
<mrkiko> f00b4r0: so all changes are in that dir?
<f00b4r0> it's common for handbuilt software to install in /usr/local by default
<PaulFertser> And that's not macOS specific.
<mrkiko> f00b4r0: ok; next "more clean" ?
<f00b4r0> mrkiko: i think that's quite off topic, but you could spawn a new APFS container, install a clean system there and then "migrate" your old data via the migration assistant.
<f00b4r0> then you delete the old volume.
<f00b4r0> this would give you a much cleaner system, since you would essentially have a fresh install + whatever you chose to move over
<mrkiko> f00b4r0: thanks
<f00b4r0> np yw
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<Ansuel> btw mkimage can compile correctly on alpine with musl but doesn't on macos in 22.03
<Ansuel> what a meme -.-
<f00b4r0> heh
<stintel> meh power outage for 40 minutes already
<Znevna> funky
<Ansuel> any idea of the reason? storm?
<stintel> no idea
<stintel> it's just the local area (few streets)
<stintel> it happens regularly but not for this long
<Znevna> windows 10 is weird
<Ansuel> ?
<Znevna> if you try to add a network using wps which is broken in openwrt
<Znevna> and you get the wrong password prompt, and you enter the right password, it still tries to use a wrong password to connect
<Znevna> x.x
<Ansuel> wps works only one time
<Ansuel> next connection will result in mismatched psk
<Ansuel> no time to bisect
<Znevna> I think it works when using only wpa2?
<Znevna> didn't try
<Znevna> I don't use it anyway :P
<Ansuel> had lots of time with a printer that loved using wps but didn't work after one day....
<Ansuel> took month to discover
<Znevna> I was trying to get my sniffing laptop online and I remembered I've played with WPS the last time
<Habbie> catching up on #openwrt-devel, i see
<Habbie> An application linking
<Habbie> statically against it has to follow the LGPL, when an application links
<Habbie> dynamically against it there is not need to follow LGPL.
<Habbie> which is simply not true
<Habbie> oops, s/#openwrt-devel/the openwrt-devel list/
shibboleth has joined #openwrt-devel
<Znevna> another case of soft bricked ax53u :<
<Znevna> rmilecki: I know you're busy, what data can I gather for the trx firmware? I have a working asuswrt based build system (swrt, I didn't bother getting the official GPL to running state) that produces proper firmwares
<oliv3r[m]> anybody know anything about SWAP_IO_SPACE https://elixir.bootlin.com/linux/v6.1.4/source/arch/mips/Kconfig#L157 ? With that option set, I can't boot LZMA compressed kernels, nor can I boot anything beyond the first 10 lines of printk's. Why is it 'so generic' and why is it not working on our realtek platform?
<robimarko> * Sane hardware offers swapping of PCI/ISA I/O space accesses in hardware;
<robimarko> * less sane hardware forces software to fiddle with this...
<robimarko> The description is great
Borromini has joined #openwrt-devel
<nick[m]12> Can someone merge 5.15 archs38 support? This is ready. https://github.com/openwrt/openwrt/pull/11705
<karlp> yet again, someone other than snps doign all their work for them I see?
<robimarko> I have sent a patch to make it source-only as target seems completely unused, download statistics are showing the same
shibboleth has quit [Quit: shibboleth]
<nick[m]12> robimarko: what about making ath25 source-only?
<Ansuel> i just realized i may have for real converted each clk driver for ipq806x to parent_data o.O
<robimarko> nick[m]12: No idea how popular ath25 is
<f00b4r0> i suspect "not very much" ;P
<robimarko> Well, it is one of those that is left to the end to convert to new kernel
<dangole> nbd: i'm observing performance degradation on mt7986 with gmac1 connected to 1G sgmii PHY. before your multiqueue patch RX and TX would both be around 930MBit/s. after multiqueue patch TX only gets up to around 670MBit/s.
<robimarko> Oh, so it was dropped in 2020 and resurected couple of days later
<dangole> nbd: commenting out the SPEED_1000 case in the patch fixes it, so I assume the values picked there are wrong
<f00b4r0> robimarko: i remember something like that yes. It's one of those that don't want to die ;P
borek has quit [Ping timeout: 480 seconds]
<f00b4r0> robimarko: then again, moving to source-only is much less abrupt than outright drop
<robimarko> f00b4r0: It did have a whopping 4 downloads of the generic image
<f00b4r0> lol
<f00b4r0> yeah i vote for moving to source-only as well
<robimarko> It is it the 10 days of january, but still
<f00b4r0> with a bit of luck nobody will notice
<robimarko> I assume most users are downstream anyway
<dangole> robimarko, f00b4r0: you'd be surprised how many ar2xxx WiSoC systems are still in use (esp. older ubnt outdoor gear, like ubnt bullet)... i know at least one place still using a bunch of them, slowly replacing them with newer ubnt outdoor gear when ever one of them dies.
<robimarko> I am not surprised, but those arent the people that update the SW
<dangole> robimarko: in this case they are even using batman-adv mesh, and yes, they are updating with every stable openwrt release (but building from source)
<f00b4r0> dangole: do they have enough storage/ram to run anything recent?
<robimarko> If they are building downstream then making it source-only wont hurt anybody
<dangole> f00b4r0: some are 8M/32M, so not soooo bad. it's more then 120~180MHz MIPS4Kc which makes you fall asleep while trying to do anything with them...
<dangole> robimarko: yes, source-only won't hurt.
<f00b4r0> *nod*. Besides 32M is no longer "supported"
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (96.2% images and 99.6% packages reproducible in our current test framework.)
<robimarko> BTW, can you poke those people to migrate the target to 5.15
<dangole> robimarko: i'm afraid it's going to be them poking me to do that, and they will do testing and report back....
<f00b4r0> heh
<robimarko> dangole: as long as somebody does it, cause its a straggler again
<dangole> robimarko: ouf... one iteration of testing is like 30 minutes on those. flashing takes like 10 minutes, first boot after upgrade another 10 minutes, ...
<f00b4r0> ugh
<robimarko> That sounds like a world of pain
<f00b4r0> have to wonder what's the point really
<robimarko> Like watching paint dry
<f00b4r0> lol
<nick[m]12> I already did the 5.15 migration
<nick[m]12> Already poked someone to test. However, I thought that they only have 4 MB flash.
<nick[m]12> If some targets have also 8 MB, I think we can still keep it. ;)
<nick[m]12> Proabaly used by some radio amateurs. I would test 5.15 myself, however, I don't own any device. :/
<robimarko> Nobody is talking about dropping it, just not building it anymore on buildbots
<nick[m]12> Okay, does not look so good anymore: https://github.com/openwrt/openwrt/pull/10837#issuecomment-1371056173
<f00b4r0> :facepalm:
<f00b4r0> inconveniently the makefile doesn't suggest the flash size of these devices
<robimarko> Mildly put, its time for these to die
<f00b4r0> that's my impression as well
<f00b4r0> i think they got a bit extra life support in 2020 but it's probably time to pull the curtain
<robimarko> damn, we are agreeing on a lot of stuff lately
<f00b4r0> Ansuel: btw you still have #11751 open but if I'm not mistaken you've merged that
<Mangix> Add the packages feed and alpine failures increase
<Ansuel> Mangix why you want me to suffer ahahah
<Ansuel> f00b4r0 will autoclose when a commit will be merged
<Mangix> most notably perl fails
<f00b4r0> Ansuel: it didn't. It shows conflict now.
<Mangix> The one in packages is old
<Ansuel> f00b4r0 trust me it will not the first time this happen. looks to be a problem with how the github fork is synced with the real git repo
<f00b4r0> Ansuel: I trust you. I just wanted to raise your awareness ;)
<Ansuel> but it's probably a bug in github
<f00b4r0> Ansuel: i get that, but that PR won't close itself unless you do it, hence me pinging. Unless we don't care about stale PRs that are already merged that is :)
<Ansuel> it will close itself
bluew has joined #openwrt-devel
<rmilecki> thank you robimarko for testing
<f00b4r0> oh dear. 1.7k GH issues. This is getting out of hand :P
<Ansuel> we still have to close the one related to deprecated openwrt version
<f00b4r0> #11650 rings a bell. I think I saw something similar on mt7621
<Ansuel> i pushed a new commit and the old pr got closed as merged
<Ansuel> no idea why but looks to be a github bug with the pr scanning
bluew has quit [Quit: Leaving]
bluew has joined #openwrt-devel
srslypascal is now known as Guest1006
srslypascal has joined #openwrt-devel
<f00b4r0> Ansuel: I see. Sorry for the noise then.
Ryncewynd has quit [Read error: Connection reset by peer]
Ryncewynd has joined #openwrt-devel
<Ansuel> nha i understand it's confusing
Guest1006 has quit [Ping timeout: 480 seconds]
<hauke> Ansuel: the github actions work again after the prebuild toolchain were updated
<hauke> Ansuel: there are some actions queued forever: https://github.com/openwrt/openwrt/actions?query=is%3Aqueued
<hauke> looks like a github bug
<Ansuel> you know the fun thing?
<Ansuel> per github ci documentation actions in queue more than 24h should be automatically cancelled
<hauke> no?
<hauke> yes I have seen that
<Ansuel> well lets just cancel them
<Habbie> github actions have been a shitshow this week
<hauke> I have also seen some which aborted becasue of an internal error
<Habbie> me too
<Habbie> artifact download broke a lot earlier this week
<Habbie> and the network sucked too, apt was unhappy a lot
<Ansuel> robimarko wonder if the change for the pre_upgrade is causing some problem ?
<robimarko> Ansuel: With what?
cbeznea has quit [Quit: Leaving.]
<Ansuel> with the device bricking
<robimarko> It cant be
<robimarko> As that is only in the latest image to which they are upgrading to
<robimarko> The thing is that nobody, quite literaly nobody has anything captured
<robimarko> And, I have really tried to brick mine but I just cant
<robimarko> Only thing I could think of is some weird bootloader thing where it changes the rootfs which its booting, but I dont see how
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
<Ansuel> hauke btw i think i will just use an action to get changed files and based on that select what to build for the kernel test
<Ansuel> it's an alternative for your pr with the script
robimarko has quit [Quit: Leaving]
<slh> what are the odds that those who did break their ax3600 during the migration might have used a qsdk based build with changed smem and everything in the past? I mean there are too many reports for mere finger trouble, but not enough to see a pattern
<slh> (although I wouldn't disregard finger trouble either)
Ansuel has quit [Read error: Connection reset by peer]
Ansuel has joined #openwrt-devel
Ryncewynd has quit [Quit: Leaving]
<Borromini> slh: you got any IPQ807x hw?
<Borromini> or still scoping it out :)
<Borromini> gotta go, later
Borromini has quit [Quit: leaving]
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
<slh> Borromini: yeah, a few...
<dwfreed> missed by 10 minutes
<slh> yeah, well, another day ;)
<Ansuel> hauke if you are interested https://github.com/openwrt/openwrt/pull/11762
<Ansuel> robimarko i'm testing a fixup for the toolchain problem
<hauke> Ansuel: thanks
<aiyion> stintel: Caught it by chance; I'm not sure whether it worked in 5.10, but it looks like in 5.15 the NanoPi R1 does not show a wifi interface and fails to scan for near networks.
<aiyion> Sorry I didn't see it earlier. Yesterdays screenlog does not show it either.
<aiyion> testing 5.10