<gch981213>
That Siflower chip isn't real yet... It's likely living on FPGA because all the devices in the final evb.dts use slow fixed-clocks instead of real clock controller.
<gch981213>
I've suggested in the PR to wait a bit for real hardware because we are lacking build resources.
<gch981213>
Qingfang told me that the chip design is already sent out for fabrication and it will be ready in June. The PR is fine besides the messy and unused clock driver. (They are refactoring that.)
<gch981213>
Should I instead suggesting them to drop the clock driver and we take it as source-only?
<robimarko>
source-only is fine, but honestly I dont see a point until there is real HW
<gch981213>
If we take it early, the later pieces to make it ASIC-ready will be smaller to review.
<f00b4r0>
agree with robimarko on that
<gch981213>
and this is the only argument I could think of.
<f00b4r0>
problem with taking bits that don't relate to real hw is what happens when $random_user tries these bits on real hw
<stintel>
I'm also leaning towards "let's wait until real HW is there"
<f00b4r0>
besides don't we require that new device support be *tested* before merge? :)
<robimarko>
Thing is that a lot of drivers will change when real HW rolls out
<f00b4r0>
^ that exactly
<robimarko>
Because the final HW aint gonna be perfect
<gch981213>
OK.
<f00b4r0>
as for smaller review, we can always suggest they make incremental changes in PR, then squash everything when it's ready
<gch981213>
f00b4r0: Oh. I'll go suggesting that.
<rmilecki>
nbd: 5 minutes with no single stall
<rmilecki>
nbd: looks promising
<rmilecki>
i'll update you in 2 hours
mcbridematt has joined #openwrt-devel
<rmilecki>
nbd: i had 2 stalls over 1 hour iperf session
<rmilecki>
it's great improvement
<rmilecki>
but I think that with buffering disabled I need to wait hours to see a single traffic stall
<rmilecki>
[another topic]
<rmilecki>
i just noticed this during boot:
<rmilecki>
[ 36.413775] do_page_fault(): sending SIGSEGV to ujail for invalid read access from 00000036
<rmilecki>
[ 36.430676] epc = 77d77757 in libubox.so.20240126[77d73000+1f000]
<rmilecki>
[ 36.442993] ra = 55644745 in ujail[55640000+14000]
<rmilecki>
it's with the latest master, on Netgear R6220 (this device has 128 MiB of RAM)_
<rmilecki>
can I se gdb or sth to check what happened?
<rmilecki>
did crash happen in 77d73000+1f000 ?
<nbd>
do you know what process ujail was supposed to start?
<rmilecki>
no, it's a very default OpenWrt setup though
<aparcar>
it's a bit funny that this wasn't touched in 7 years
<aparcar>
so for imagebuilder etc we use multithreaded compression with xz
<f00b4r0>
another technical reason to ditch xz ;P
<KanjiMonster>
yep
<KanjiMonster>
(no idea which checksum xz produces when using -T0 on a single core machine)
<robimarko>
Yeah, we should get rid of it ASAP
<aparcar>
robimarko: i saw you and ansuel did some commets there, do you want to continue the work?
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<robimarko>
aparcar: Ok, Ansuel already did some work yesterday
<jow>
after reading https://www.nongnu.org/lzip/xz_inadequate.html (whiuch might be slightly biased because it's written by the lzip author) I would not consider xz suitable for anything
<jow>
at least not for the purpose of packing / distributing or archiving sources
<f00b4r0>
jow: regardless of bias, the technical arguments there are undisputable (and undisputed, afaik)
<jow>
so personally I'd vote to end the .tar.xz craze and simply revert to .tar.gz or maybe zstd if this is the hot stuff nowadays
<f00b4r0>
*nod*
<jow>
not sure why we even started using it in the first place, I think it just "happened"
<f00b4r0>
btw, the commit pointed out by aparcar on #14971 is a good illustration of everything wrong with xz, starting with upstream apparent unawareness of the consequences of their changes:
<f00b4r0>
jow: I'm guessing "look 'ma, maximum compression!"
<jow>
I am more worried about the apparent deficiencies in the .xz format itself
<f00b4r0>
yeah. It's brain damaged all right.
<stintel>
aha should get an EAP683LR tomorrow
cmonroe has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<nbd>
i'm in favor of switching to zstd as well
<KanjiMonster>
though we can't drop xz, as most external tarballs are xz compressed (unless we add it as a host prereq, and then we didn't win anything)
<Znevna>
that might change
<nbd>
well, we have zstd in tools/ already
<nbd>
sorry, wrong window
<KanjiMonster>
right, I wasn't arguing against using zstd for anything we create, just against dropping xz, as (currently) we still need it (commented also in the PR)
<f00b4r0>
my gut feeling is, that requirement is going to go away rather sooner than later
<f00b4r0>
every sensible upstream is going to come to their senses
<f00b4r0>
also how many of these upstream provide both xz and gz tarballs
<KanjiMonster>
with so many packages, some barely maintainted, I wouldn't be too sure. My expectation is many months. And then you have the issue that going back to older versions may require xz again. Though the gz option likely stands for many packages.
<f00b4r0>
"some barely maintained -> maybe a good opportunity to prune our repo? ;)
<robimarko>
It will not be built first like it currently is
<KanjiMonster>
robimarko: but most tools use .tar.xz source tarballs, don't you still need to build it very early to be able to extract their sources?
<robimarko>
KanjiMonster: we can move to .gz tarballs instead
<robimarko>
Though I get your point
<robimarko>
XZ is still built first it seems
<f00b4r0>
i'd second moving to gz everywhere it's possible
<KanjiMonster>
robimarko: as I already pointed out, .gz is not always an option, some tools only provide .xz tarballs ;-)
<robimarko>
Cant we just use GIT directly in those cases?
<KanjiMonster>
unfortuntely the autoconf-archive git is only reachable via git://, so switching to that would make OpenWrt unbuildable behind firewalls allowing only http(s)
<KanjiMonster>
ah, actually it does
<Znevna>
pinging them via email might make them change the archive format in light of recent event? :P
<Znevna>
events too
<robimarko>
KanjiMonster: I will move all tools that have GZ or other alternatives from XZ
<robimarko>
Some will have to remain currently
<nbd>
KanjiMonster: i wouldn't worry too much about git:// and firewalls - after the snapshot builds are done, the build system will download the tarfiles from our server anyway
<aparcar>
Mangix: ideas why bzip2 doesn't compile on macos?
<aparcar>
nbd: or you actually?
<nbd>
because of -soname
<aparcar>
do we actually need the package in tools? is any source ever bzip2 compressed?
<aparcar>
oh nevermind, the correct suffix is bz2 and there is plenty
<nbd>
i'll fix it
<aparcar>
ty
<aparcar>
once that's working I add it to automated CI tests
<ynezz>
nbd: BTW I was asking about the xz from your host (staging_dir/host/bin/xz), as in your case, this is probably built using clang on macOS, right?
<ynezz>
so I was just wild guessing, that the compiler produces different .xz due to some optimization crap
<nbd>
this has nothing to do with my host or my compiler or optimization
<ynezz>
yep, its all clear now from that linked github pull request
<aparcar>
ynezz: you closed a bunch of gitlab openwrt issues, are you done with it?
<ynezz>
aparcar: someone pointed to 3y old merge request there, so I've made it clear, that this was really just for testing/evaluation
<aparcar>
ynezz: thanks for taking care
<ynezz>
will try to cook some script and turn off the issues/merge request features
<aparcar>
I though of addming mirrors to codeberg.org at some point, also disabling everything
<aparcar>
but that is a hetzner hosted thing which I find appealing
<ynezz>
so they've no CDN in front?
<aparcar>
afaik yes
<ynezz>
good, should make it more accessible to folks in US sanctioned countries etc.
<aparcar>
yea
<aparcar>
and overall a nice fallback for people concerned with github, I'd say
<f00b4r0>
what's wrong with git + email though? :)
<aparcar>
right, don't feed the troll
<f00b4r0>
well i'm not trolling, the point is we're shorthanded right, so maybe not spending (wasting) time on multiple fronts would help?
<f00b4r0>
but you're welcome to disagree without being insulting.
swalker_ has joined #openwrt-devel
cmonroe has quit [resistance.oftc.net larich.oftc.net]
Mangix has quit [resistance.oftc.net larich.oftc.net]
mattsm has quit [resistance.oftc.net larich.oftc.net]
fakuivan has quit [resistance.oftc.net larich.oftc.net]
jkl has quit [resistance.oftc.net larich.oftc.net]
johnf has quit [resistance.oftc.net larich.oftc.net]
Snuupy has quit [resistance.oftc.net larich.oftc.net]
cyrozap has quit [resistance.oftc.net larich.oftc.net]
swalker has quit [resistance.oftc.net larich.oftc.net]
slingamn has quit [resistance.oftc.net larich.oftc.net]
linusw has quit [resistance.oftc.net larich.oftc.net]
h2t has quit [resistance.oftc.net larich.oftc.net]
russell-- has quit [resistance.oftc.net larich.oftc.net]
<mrnuke>
However, if htmode is empty, it passes an empty string to 'iw ibss join" which casues the command to fail
<mrnuke>
For example, "iw dev phy0-ibss0 ibss join crymesh 2412 '' fixed-freq beacon-interval 100" which will fail
<mrnuke>
nbd: ^ Tracked it down to commit e56c5f7b276a ("hostapd: add ucode support, use ucode for the main ubus object"). I am working on a patch. Is there a process to get it into the 23.05 release as a fix?