<f00b4r0>
yeah i think it doesn't make sense at that point
<f00b4r0>
it barely did when 21.02 was branched
<robimarko>
Its also extremely low on RAM
<robimarko>
So I dont know how is it even working at all
<f00b4r0>
yep. IMHO we should drop this target, it's purely theoretical at that point. But we can start by turning it source only and checking if someone complains
<robimarko>
It seems that there were users, but they were all building downstream images anyway
<f00b4r0>
all the more reason then
<karlp>
ath25 finally made it upstream, just as all the devices became obsolete :)
<robimarko>
I am looking at download statistics and they are abysmal
<robimarko>
Like 3-5 downloads
<f00b4r0>
robimarko: care to submit a patch? :)
<karlp>
yeah, there's no board support for ath25, so you ~must build your own custom one.
<f00b4r0>
karlp: *nod*. so it doesn't make sense to waste our buildbot resources on that.
<robimarko>
f00b4r0: You really like for me to poke the hornets nest
<f00b4r0>
well you have some success there ;)
<karlp>
I tipped the our last ath25s into an ewaste skip almost three years ago now :| source only all the way :)
<karlp>
but it was a little bittersweet seeing that alexiy? somebody finally getting it all upstreamed.
<robimarko>
Ok, will send a patch to the mailing list to make it source-only
<f00b4r0>
robimarko: also my assigned hornets nest is the buildbot software, I can't bother the powers that be too much...
* f00b4r0
winks at ynezz
<robimarko>
f00b4r0: BTW, We are quite behind the current buildbot version
<robimarko>
Well, 2-3 versions at least
<f00b4r0>
i know. I've tested 3.6.x when I made all the changes (it was current at the time) so I know that works. But it's the same bottleneck ;)
<gch981213>
I remember our conclusion from last discussion on retiring ath25 (The 5.10 bump?) is that we keep it until something breaks :P
<robimarko>
We are talking about just making it source-only
<robimarko>
So that buildbots dont build it
<f00b4r0>
gch981213: not being able to boot a kernel because it's too big seems like it would check that box. But as robimarko said, we'll do babysteps ;)
<robimarko>
It also needs to be updated to 5.15 kernel anyway
<f00b4r0>
last time Adrian was a bit more expeditious ;)
<f00b4r0>
yeah I think that's exactly what's going to kill it: no one able to test it works.
<gch981213>
robimarko: Ah. That makes sense. There's no way the default config works on 32M ram these days.
<robimarko>
f00b4r0: Done
<f00b4r0>
👍
<neggles>
gch981213: ah, but some people are insane and upgrade the ram on things that do not in any way deserve it
<gch981213>
neggles: ath25 can only be upgraded to 32M
<neggles>
touche.
<neggles>
I mean I'm nuts but even I'm not touching anything ath25 :P
<neggles>
old mt762x is the farthest I'll go, and only because nobody makes the formfactor/featureset i want for a couple of specific devices with anything newer/nicer
<neggles>
(as a result I am 2/3 done with doing it myself using something shiny and new)
<neggles>
you can fit a lot of SoC in a QFN-88 these days
<neggles>
oh, speaking of weird SoCs - has anyone done any work on riscv64 lately?
<robimarko>
Currently for: - HiFive Unleashed - FU540, first generation
<robimarko>
- HiFive Unmatched - FU740, current latest generation, PCIe
<neggles>
The JH7110 and FU740 have a lot in common
<neggles>
StarFive is basically "SiFive: China Edition - now with more ex-Allwinner engineers!"
Guest1495 has quit [Ping timeout: 480 seconds]
<neggles>
this particular board is of questionable use as a router, one of the ethernets is only 10/100 because of PHY shortages
<neggles>
but the VF2 is already on a 5.15 kernel that's not actually all that modified compared to upstream
<f00b4r0>
still have to try mine
<neggles>
a lot less hacked up than the usual android-based ones anyway...
<neggles>
f00b4r0: something is screwy with the GPU drivers in v69 Debian image they provide, I get oopses when X starts and when I run glmark2-es2
<jow>
robimarko: for ath25 I'd consider providing sdk and imagebuilder still
<jow>
robimarko: but disabling all images
<f00b4r0>
I think stintel went through gpu problems as well
<neggles>
also you'll have to flash the SBL/U-Boot + clear env vars before it'll boot it
<jow>
then after the next release drop (source-only) it entirely
<f00b4r0>
jow: the problem is that there's no way one will be able to run a 5.15 system on 32M
<robimarko>
Yeah, I dont see how its gonna run with the max of 32MB of RAM
<f00b4r0>
right now nobody is able to test that kernel
<f00b4r0>
so I'm not sure what's the point, really?
<jow>
ok, I read the message as if people still use it downstream but with custom builds
<f00b4r0>
they use current 5.10 custom builds
<robimarko>
Yes, I assume heavily modified
<f00b4r0>
aiui
<jow>
ok
<neggles>
You could make 5.15 work on 32MB, but you'd have to cut out absolutely everything you weren't using, and pray
<jow>
what makes it so fat?
<f00b4r0>
bit inflation ;P
* f00b4r0
hides
<neggles>
the kernel source tree is up to 1.3GB uncompressed
<neggles>
there's just, a lot of stuff in there
<robimarko>
dangole is the one that had interactions with guys using this thing downstream
<robimarko>
We had a discussion on January 10th here on IRC
<jow>
ok
<f00b4r0>
jow: we've discontinued support for 32M devices in 21.02; so nearly two releases down, I think it's time to pull the plug, is it not?
<f00b4r0>
besides if there are actually users that care, they will have an opportunity to be heard with this "visible" change
<jow>
sure, pull ahead
<f00b4r0>
👍
<neggles>
yeah
<jow>
neggles: I know that the source tree is large, that doesn't answer my question though. And I do know that every kernel release grows in every subsystem equally. Just was wondering if 1.15 has some notable, specific things that tip usability on 32M over the edge compared to 5.10
<jow>
*5.15
<neggles>
There are a number of new things in MM compared to 5.10 iirc, but it's been a while so I'll have to check
<f00b4r0>
jow: aiui 5.10 was already very much on the edge
<jow>
we should consider brcm47xx legacy too
<f00b4r0>
so it's probably just the proverbial last straw
<robimarko>
I guess we will see more and more old bootloader kernel size limits being an issue
<wigyori>
neggles: i have a target for the visionfive1 as well - vf2 will probably be based on 6.1 as a boatload of stuff would need to be backported
<wigyori>
neggles: if you're interested in it, i'll do some testing and then put it into my staging
<dhewg>
does anyone know if I need to consider hw properties of external antennas when exchanging those?
<dhewg>
I have some left from some 5g device, can I just use them for another 6g card?
Ansuel has joined #openwrt-devel
<Ansuel>
jow can the ipq807x target be added to buildbot? for packages we already have coartex-a53 so not needed there
<jow>
Ansuel: once it's is restarted it should pick it up
<Ansuel>
also archs38 should be removed since it's source only now and won't produce any image i guess
<jow>
waiting for ynezz to do it
<Ansuel>
okok thanks a lot
<jow>
s/waiting/hoping/ :)
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
valku has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
<soxrok2212>
robimarko: any ideas about 2.5g negotiation on 301w?
<robimarko>
soxrok2212: In what sense?
<robimarko>
The reason why they are not advertised in the upstream AQR commit
<soxrok2212>
well, not quite that, but rather why the speeds are abysmal when it negotiates at 2.5g
<robimarko>
Not really, I am suspecting the stupid clock calculation logic they are using
<robimarko>
I suspect they remain at 125MHz which is for 1G instead of 312.5MHz for 2.5G and above
<robimarko>
Havent really had time to poke at that
<soxrok2212>
okay cool, is that changeable on the fly or would drivers need to be rebuilt to test
<robimarko>
Nope, its part of the clock source code
<soxrok2212>
okay last question, anything else i can provide to you to help get it fixed?
<robimarko>
Not at this moment, I will probably have some questions/tests later, but I can always reach you on the forum
<robimarko>
Or here
<soxrok2212>
got it. thanks!
<Znevna>
rmilecki: how's your schedule this week? ^^
G10h4ck_m has joined #openwrt-devel
<G10h4ck_m>
Hello
<G10h4ck_m>
nbd how are you? I have been progressing with the 4addr stuff
<nbd>
hi
<nbd>
fine, thx
<nbd>
how about you?
G10h4ck_m has quit [Read error: Connection reset by peer]
<nbd>
hrm
G10h4ck_m has joined #openwrt-devel
<nbd>
G10h4ck_m: hi
<G10h4ck_m>
I have sent to you some updates via email, but I am not sure you are receiving it
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
<nbd>
received them, but didn't have time to look at them yet
<nbd>
i will try to find the time soon
<G10h4ck_m>
Now I am at the point that the Ap WDS is added as station, the interface is created, it even appears in 'iw station dump'
<G10h4ck_m>
The kernel doesn't complain
<G10h4ck_m>
Butbi don't get the packets
<G10h4ck_m>
Tx counter stays 0
<G10h4ck_m>
RX goes all miscellaneous dropped, or something similar
<nbd>
did you check if the station is fully authorized?
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
<G10h4ck_m>
Iw report it is
<G10h4ck_m>
But I don't know how to debug it properly beside what is reports
<G10h4ck_m>
The kernel says nothing in dmesg
Acinonyx has quit [Ping timeout: 480 seconds]
<G10h4ck_m>
Everithing seems fine in the logs
Acinonyx has joined #openwrt-devel
G10h4ck_m has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
G10h4ck_m has joined #openwrt-devel
<G10h4ck_m>
The code I have written is horrible for now, but it is only in one place so if you can take a rapid look to see if something obvious is missing
<G10h4ck_m>
The link is in the latest mails, I am on the phone now
Ansuel has joined #openwrt-devel
G10h4ck_m has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: No route to host]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
G10h4ck_m has joined #openwrt-devel
srslypascal is now known as Guest1513
srslypascal has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
Guest1513 has quit [Ping timeout: 480 seconds]
G10h4ck_m has quit [Ping timeout: 480 seconds]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: No route to host]
G10h4ck_m has joined #openwrt-devel
Paradox17 has joined #openwrt-devel
Paradox17 has quit [Remote host closed the connection]
G10h4ck_m has quit [Remote host closed the connection]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
G10h4ck_m has quit [Ping timeout: 480 seconds]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
<dangole>
stintel: ok, will take care of it. thank you for pointing it out
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
<stintel>
dangole: thanks, I mentioned you in one of the comments last week but I guess you didn't get notified of that
<stintel>
dangole: and just in case you didn't scroll down, I linked a commit hash with a fix
<dangole>
stintel: i guess i did get notified but the notification drowned between hundreds of other github notifications...
hanetzer has joined #openwrt-devel
<stintel>
yeah, github is a disaster
<dangole>
stintel: seen the commit fixing it, i'm about to apply something more simple (acct ? acct->foo : 0) instead
<stintel>
was considering the same
<dangole>
stintel: so the output format stays identical to what you can find in mtk sdk...
<stintel>
I see
<stintel>
didn't look at mtk sdk
<stintel>
I'll probably switch ramips to 5.15 default after you fix that in master
<dangole>
stintel: that's where the patch came from, i extracted from there and polished a bit to make it
<stintel>
gotcha
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
<Ansuel>
guys since archs38 is source-only is it ok to switch to 5.15?
<Ansuel>
by default i mean
<stintel>
sure
<stintel>
nobody cares about archs38
<Ansuel>
poor target :(
<stintel>
maybe we should put its removal on the next meeting agenda
<Ansuel>
mhhh patches are minimal so it's not that problematic to bump i would keep it as source only as we found at least one user
<stintel>
was anything ever available on the market even?
<stintel>
it was contributed by the guys making the stuff, but they don't seem to be contributing anymore, and we're also still waiting for musl support
<robimarko>
Doubt that musl support will ever emerge
<stintel>
yeah so we should just drop it imo
<robimarko>
I am not against, seems that only Synopsys uses it
<robimarko>
At least its always the same guy from them testing the new kernel
<stintel>
it should be this guy sending us the bumps (early)
<stintel>
Ansuel: I'd rather keep default n, it's more readable, and if Kconfig ever decides to change default, we'll not have impact
<stintel>
(just my 2 cents)
G10h4ck_m has quit [Read error: No route to host]
<robimarko>
Will buildbots pickup the new target automatically?
<stintel>
nope
G10h4ck_m has joined #openwrt-devel
<Ansuel>
think is that afaik :=n is not advised as by default everything is n and they suggest # CONFIG... is not set for disabled stuff
<robimarko>
stintel: Is it poor ynezz that is the one to bother with it?
<stintel>
dunno
<Ansuel>
robimarko it needs to be restarted
G10h4ck_m has quit [Read error: Connection reset by peer]
<Ansuel>
and he needs to do that
<Ansuel>
jo warned him already so i think we should wait
<robimarko>
Ok, that is fine
G10h4ck_m has joined #openwrt-devel
<robimarko>
Thanks, I am not really familiar with the buildbots
<karlp>
I'm 100% on board with arc being dropped unless snps maintains it themselves. it was allowed in with glibc on the promise that they would get it up to par, they didn't. toss it out
G10h4ck_m has quit [Read error: Connection reset by peer]
cbeznea has joined #openwrt-devel
G10h4ck_m has joined #openwrt-devel
G10h4ck_m has quit [Read error: Connection reset by peer]
G10h4ck_m has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
<dhewg>
Ansuel: seen my latest iwinfo comments? Is there anything I can do to push it over the finishing line?
<dhewg>
oh wait, ofcouse I get a noticifation one sec after posting that...
<dhewg>
ok, minus the mt patches then :)
G10h4ck_m has quit [Ping timeout: 480 seconds]
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #openwrt-devel
<Ansuel>
dhewg still not sure about the restriction change... i think i will follow your strategy and just flag as restricted with no_ir
<Ansuel>
then work on luci for an implementation and implement a general approach for the restriction value?
<dhewg>
with the latest PR restricted is still present and unchanged
<dhewg>
but then restricted is just flags&NO_IR
<dhewg>
I mean we can just leave it at that, but now that all those nice flags are exposted luci and whatever can just use that, no?
<Ansuel>
the idea was to have a global flag to understand if a channel is free of any restriction or not and then check what is needed
<Ansuel>
mhhh from luci i think that can be changed to simply checking if the array is empty or not
<dhewg>
Yeah, but is that practical? To really mean something iwinfo need to know if the radio is in or outside
<Ansuel>
we really don't know but this thing is similar to the reg domain thing... is the router really in japan to use channel 14 ?
<dhewg>
the reg influences those flags
<dhewg>
which is why I get INDOOR_ONLY for everything 6g
<Ansuel>
the restriction thing is really to tell the user that he should not use that channel outside. We have no way to verify if the router is inside or outside... User choice to go against emission law
<Ansuel>
don't know if you checked the pr for luci
<dhewg>
ok, but that implies a luci change. right now it refuses to offer channels where restricted=true
<dhewg>
and then there're libiwinfo users, lua bindings included. where restricted is already exposed
<Ansuel>
and this is why i think i will just leave the flag as is and flag as something to drop but i would love jow feedback on that
<dhewg>
ok, but that sounds like we agree then? ;)
<dhewg>
that's exactly what the latest batch of patches do
<jow>
Ansuel: dhewg: that restriction flag was once added to omit channels in the selection that would lead to a radio not starting
<jow>
e.g. when chosing channel 12 or 13
<jow>
the entire radio configuration concept in luci needs a complete overhaul, it jsut became too complicated
<jow>
also regdomain rules
bluew has joined #openwrt-devel
<jow>
sometimes they change on the fly (due to received beacon info), sometimes they change after the radio is brought up
<jow>
they alos change or might change if the country is changed
<jow>
instead of a naive dropdown with channel numbers, it should probably be some kind of multi-step selection wizard
<jow>
in case of a dfs channel being selected, we probably should additionally ask for the allowed list of fallback channels
<jow>
etc.
<dhewg>
a wizard would probably fit pretty well
<Mangix>
Ansuel: hand's broken. can't update PRs for now.
<dhewg>
there's also the NO_X_MHZ flags which are not used at all
<jow>
first ask the user for the country, thne for the esired minimal channel width
<jow>
then maybe ask for outdoor or not
Lynx- has joined #openwrt-devel
<dhewg>
yeah, something like that
<jow>
then confirm, apply the chosen country as regdomain in the background, then query the effectively loaded regdom rules and present the user with a list of channels and their restriction flags in a tabular way
<dhewg>
does nl80100 take those beacon infos into account when it returns its data and flags?
<Ansuel>
Mangix I need to ask... it's a joke or you actually.... ?
<Mangix>
not kidding no. i'm typing with one hand.
Ansuel has quit [Read error: Connection reset by peer]
Ansuel has joined #openwrt-devel
<Mangix>
funny. fish history has that dsa python script
<neggles>
wigyori: very much interested, yes :)
<neggles>
dhewg: most wifi antennas (especially ones intended for dual-band use) are nowhere near well-tuned enough for it to matter
goliath has quit [Quit: SIGSEGV]
<neggles>
for a basic stick/rubber-ducky type antenna, if it works reasonably well on 5GHz, it'll work pretty much as well on 6GHz (and certainly won't damage anything)
<stintel>
neggles: o/
<neggles>
stintel: hey! how's it goin'?
<stintel>
ssdd ;p
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<Mangix>
Ansuel: anyway, just merge whichever PR. I rebased the unpack one on top of oliv3r[m] 's
Ansuel has quit [Read error: Connection reset by peer]
Ansuel has joined #openwrt-devel
<Mangix>
Ansuel: anyway, just merge whichever PR. I rebased the unpack one on top of oliv3r[m] 's
Ansuel_ has joined #openwrt-devel
Ansuel has quit [Read error: Connection reset by peer]
<neggles>
stintel: big mood :P
<wigyori>
neggles: ack :)
<neggles>
'cept now I have a bunch more shiny things, and a couple more O C T E O N S in the pile of "things to OpenWrt"
<neggles>
(octeon-IIIs, at least)
dangole_ has joined #openwrt-devel
<neggles>
oh hm I should probably go back to the sophos APX530 too, is ipq806x in any better state than a year or two ago? :P
<Ansuel_>
what was so special on that device?
<neggles>
nothing really, but last time I looked into it ipq806x had just been removed
dangole has quit [Remote host closed the connection]
<Ansuel_>
removed?
<neggles>
it was uh, a while ago. before 21.02
<slh>
s/ipq806x/ipq807x/ ?
<Ansuel_>
it's probably 7x
<slh>
back then, the ipq807x target as removed from git didn't support any physical device at all, very bare bones
<Ansuel_>
yep i remember
<slh>
what Robert and Ansuel merged today has 7 fully working devices merged on day one, with at least 3-4 close to working ones
<neggles>
hm
<neggles>
you're right about the target removal
<slh>
pending in various states of development - and ipq60xx isn't completely out of the picture now either
<Ansuel_>
slh in theory each of them works correctly
<neggles>
there was *something* about ipq806x... but it was almost 3 years ago so i forget
<Ansuel_>
each wifi card and port works correctly
<Ansuel_>
slh work on ipq807x improved situation for ipq60xx indirectly
<neggles>
I do have a whole bunch of ipq807x things floating around
<slh>
Ansuel_: I was referring to the pending devices not parrt of this PR (SXR80/ SXS80, nbg7815, rax120v2, ...) the ones that didn't make it into robimarko's branches, because those weren't fully ready, yet
<Ansuel_>
oh ok
<Ansuel_>
well as ipq806x... most device are just reference board with minimal changes to the eth conf
<Ansuel_>
fun thing now we are analyzing nss handling to check if we can manage to find if the internal switch have support for hw checksum...
<neggles>
hmm... there was definitely a reason I didn't open a PR for APX530
<neggles>
can't remember why
<Ansuel_>
i just fixed my patch that converted nss-drv to normal dma api so kernel patch are not needed for that thing to run (just missing nodes)
<Ansuel_>
but i expect tons of report from user bricking their device for not reading the wiki/warning :D
<Ansuel_>
as soon as buildbot start building the target
<Ansuel_>
neggless if it was too much early it may be not compatible with ath11k
minimal has quit [Quit: Leaving]
<Ansuel_>
it was the case for the rax120v1
csrf has joined #openwrt-devel
<neggles>
APX530 is 802.11ac / ipq8068
<neggles>
i vaguely recall some screwery with ath10k
<neggles>
and that i was trying to work out which GPIOs were used to control power to the bluetooth chip
<Ansuel_>
no source?
<neggles>
I have source, but Sophos didn't end up using the bluetooth in the release firmwares
<neggles>
and there is conflicting information in the comments in the sources
<Ansuel_>
the linux source are dt or arch based?
<Ansuel_>
there may be some hint there
<neggles>
arch, and there are, there's comments which are surprisingly details
<neggles>
s/details/detailed
<Ansuel_>
board-ipq806x.c right?
<neggles>
sophos make *really* good GPL tarballs, and this is a Wistron NeWeb-made device and I've found they usually do pretty good work
<neggles>
um lemme pull it up
<slh>
bluetooth support shouldn't be a concern for getting the device merged (even less if the vendor never used/ advertised it in the first place), that could come later (when ready) - or never
<neggles>
Ansuel_: ah that's right - the devicetree has a different set of pins to what's listed in comments in the u-boot source
<neggles>
slh: yeah, I came to the conclusion that it's probably missing a pull-up or the BT chip just has zero firmware flashed to it, and the chip's only been installed because it was on there during FCC testing
<Ansuel_>
the good old days when chip shortage wasn't a thing ahahha
<Ansuel_>
an extra dummy bt chip WHO CARES
<neggles>
I mean I *still* see CSR8811s thrown into devices that don't use them :P
<neggles>
recertification is still more expensive and time consuming than qcom BT chips that still cost under a dollar
<slh>
quite a few mesh APs have that as well, in many cases also not used by the vendor
<Ansuel_>
i can only guess their idea was to use bluetooth as a way to have easy configuration from a phone
<slh>
probably though to be used for initial configuration over bluetooth, but never used as such (nor for anything else)
<neggles>
not really, they have a software suite for using it for self-configuring mesh
<neggles>
so far i've only seen it implemented in one tp-link deco product
<neggles>
I found the binaries and firmware blorb for it in there, couldn't get it to load on apx530 though so it's probably just not happening
<neggles>
when it was new, sophos marketed the APX530 as having BT beacon tracking and BT-coordinated mesh capabilities "in a future firmware"
<neggles>
but quietly dropped that from the spec sheet 6 months in
<neggles>
"found the binaries and firmware blorb for it in there" - in a tp-link deco firmware i mean
<Ansuel_>
the 6.1 discussion about lts is just a joke...
<neggles>
but anyway, yeah, no reason to not support it without the BT
<Ansuel_>
poor greg
<slh>
yep
<neggles>
is greg throwing his annual "the last release of the year isn't just automatically an LTS!" hissyfit?
<neggles>
(he's right, mind you)
<Ansuel_>
yes...
<Ansuel_>
he asked if 6.1 was mature enough and people started with RUST IS A PROBLEM AHHHHHHHHHHHHHHH
<neggles>
oh that's not the usual one
<slh>
weird, I can compile (and use) v6.1 just fine without any rust dependencies being present in the build chroot
<neggles>
you sure can
<slh>
yeah, not a surprise at all
<neggles>
if rustc isn't present, rust doesn't even show up in the menu
<slh>
just the whining about it is
<Ansuel_>
slh yep that... rust is just an addition... nothing core is absed on that it's just kernel supporting that
<Ansuel_>
nothing more
<Ansuel_>
so the complain makes no sense at all...
<slh>
I still don't consider rust support to be a good idea, but at least so far it's inobstrusive enough to totally forget about it
<Ansuel_>
also fun thing i notice some user top posting... suggesting we are starting to get also not kernel dev in that discussion
<neggles>
there isn't even anything *in* 6.1 that uses it