PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openwrt-devel
robimarko has joined #openwrt-devel
Borromini has joined #openwrt-devel
<olmari>
I'm no HC dev but immediately looks more readable
<rmilecki>
so is there a way to add Acked-by to commits in GitHub?
<robimarko>
Only manually
<oliv3r[m]>
I'd be happy to get that on those comments, as i got a NACK from someone else :) so more acks hopefully outweight the nack :D
<oliv3r[m]>
that was btw a really nice feature of bitbucket; you had a checkbox; and ticking it would automatically add the acked-by (or reviewed-by) to the commit message. Not sure if they only did it with the merge(commit) or re-wrote those commits ...
<robimarko>
The thing is that PR-s on OpenWrt arent merged via Github anyway
<Borromini>
does the bot always mark PRs as merged?
<robimarko>
So one of the devs with commit access will pick the commits into his own git.openwrt.org tree
<robimarko>
And then push them
<oliv3r[m]>
Sometimes I do see 'merged' on github PR's; not sure if that's just git being smart (if the commit is exactly in master, and git(hub) figured this out or not)
<robimarko>
oliv3r[m]: personally I dont have anything against properly sorting the tools
<stintel>
mrkiko: unable to repro again so far
<mrkiko>
stintel: thanks
<stintel>
mrkiko: I suspect it could be silent corruption in the fs from some previous 5.15 kernel but after formatting and running 5.15.82 no longer triggers
<stintel>
but that's guess
<oliv3r[m]>
<robimarko> "oliv3r: personally I dont have..." <- great :) now I have to confince ansuel :p
<mrkiko>
stintel: tanks. I'm little bit "scared"...
<stintel>
mrkiko: I'll dish out some rpi4 and try flash those
<stintel>
but I flashed m300 yesterday multiple times after recovering both and didn't hit it anymore
<stintel>
also couldn't reproduce in an x86 vm
cbeznea has quit [Ping timeout: 480 seconds]
<mrkiko>
stintel: thanks
cbeznea has joined #openwrt-devel
<stintel>
looked a bit at procd to try and improve the behavior but didn't figure out yet where loop device teardown happens
<stintel>
ehr fstools
<robimarko>
nbd: Any chance you can make the backports source you used to generate the 6.1-rc8 ones public?
<nbd>
will do
<robimarko>
Thanks, I figured out why malta/be failed
<robimarko>
In ath11k thermal.h has #if IS_REACHABLE(CONFIG_THERMAL)
<robimarko>
Which is true as with all kmods CONFIG_THERMAL will be m
<robimarko>
So, I need to patch it like ath10k does
<karlp>
oliv3r[m]: I'd say you should move to the third way, tools-y += one-entry for each tool
<karlp>
avoids the fails with last entry not wanting the \
<oliv3r[m]>
I don't mind doing that; if I can get consensus on people actually wanting this change :)
<karlp>
and allows you to add comments on each line without silently destroyign the rest of the entries below it...
<oliv3r[m]>
I think it matches nicely with the rest too
<oliv3r[m]>
I like that idea; i'll do that :)
<karlp>
not my barrel of monkeys, but I use one per line in my own stuff :)
<mrkiko>
stintel: what does it mean "top-posting" in mailing list?
<stintel>
reply above the original message vs below / inline
* stintel
blames microsoft
<stintel>
once I got a mail from a finance department of a client, asking to confirm something, I confirmed below, get an answer "confirmation not received"
<dwfreed>
top-posting is the email equivalent of putting the cart before the horse
<stintel>
😂
<dwfreed>
I do it if the horse is not particularly important :D
<karlp>
it's so not, it's just greybeards deciding things should remain in one form forever.
<oliv3r[m]>
dwfreed: like tug-boats work then :D
<stintel>
I'm not grey and I don't have a beard :P
<dwfreed>
I'm 30, and top-posting is generally bad
cbeznea has quit [Read error: Connection reset by peer]
<oliv3r[m]>
karlp: I have the same feeling; its fine the way it is :p; anyway I just pushed your stuff too
<oliv3r[m]>
your idea*
<dwfreed>
unless, as mentioned, the message you're replying to is not really needed for context
<Borromini>
doesn't *everyone* outside of IT top post?
<stintel>
Borromini: see my microsoft comment ;)
<stintel>
outlook default ...
<karlp>
can you top post badly? absolutely.
<Borromini>
:P
<karlp>
can you bottom post badly? absolutely.
<Borromini>
gmail as well.
danitool has joined #openwrt-devel
<stintel>
and every enterprise uses outlook
<stintel>
did I write fisherprice wrong?
<karlp>
greybears with clients that auto set the cursor to the end of the email, "because, lol, bottompostordie" and then put in their mail and send without trimming are just as horrific, and IMO worse than top posting.
PaulFertser has quit [Read error: Connection reset by peer]
cbeznea has joined #openwrt-devel
<mrkiko>
So guys, in all my mails I do top-posting, without knowing it actually...
<karlp>
unpopularpuffing.gif or something :)
<Borromini>
mrkiko: you heretic!
<mrkiko>
Borromini: :D
<Borromini>
Rome burns once more! :P
bluew has quit [Ping timeout: 480 seconds]
<mrkiko>
:D
PaulFertser has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest2231
srslypascal has joined #openwrt-devel
Guest2231 has quit [Ping timeout: 480 seconds]
<f00b4r0>
Not all top-posting is bad. Suppose you have a very long email and you just want to say it's completely bollocks (or ACK, if you're the positive type); one line at the top speeds up processing, there isn't even a need to load the entire message :}
srslypascal has quit [Ping timeout: 480 seconds]
<Tapper>
f00b4r0 this is true and it's even better for blind people using a screen reader. I do get why sited people don't like it tho. All so when on the website for the email list it helps to make sence of the mails.
cbeznea has joined #openwrt-devel
srslypascal has joined #openwrt-devel
<f00b4r0>
Tapper: I wouldn't think sighted people "don't like it". I think it's more prevalent in the FOSS community with strongly ingrained "standards" :}
<f00b4r0>
most of the C-suite world top posts, in my experience.
PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openwrt-devel
danitool has quit [Remote host closed the connection]
<Znevna>
I always top post x.x scrolling to the end passing all the huge signatures and disclaimers just to find an 'ok' is pain
Gaspare has joined #openwrt-devel
schwicht has joined #openwrt-devel
dangole has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
danitool has joined #openwrt-devel
<mrkiko>
why do sighted people dislike the practice? I am asking naively, I don't know the answer.
<robimarko>
Because it gets crazy after couple of replies
<hell__>
Top-posting is fine for a short reply about the entire email. However, we prefer interleaving our responses for longer replies, as we typically tackle one section at a time.
<robimarko>
Yes, not to mention when there is multiple points or questions
<robimarko>
Way easier to just reply directly in sections
<aiyion>
I found it would fix the boot issues on my nanopi r1, if we used UUIDs depending on `${mmc_bootdev}` and `${mmc_bootpart}` instead of a hardcoded `mmcblk0p2`.
<aiyion>
The router has been mixing up partitions while booting for a while now.
<aiyion>
(#10080, #11104, #11469)
<aiyion>
Currently I patched the default file to resemble the a64 one regarding the UUID.
<hell__>
We've used a screen reader before to experience what it feels like. We had a university assignment about accessibility, and we decided to make it useful: we assessed the accessibility of https://coreboot.org and then sent patches to address various problems we found.
<aiyion>
Could that break something for other sunxi devices?
<Tapper>
hell__ thanks for that work. I get in to a rage some times on just ho much some people can fuck up the A11Y on a website.
<karlp>
I'd say that "inline" is not "bottom posting"
<hell__>
"middle posting"
<Tapper>
Having a quick look at the site for coreboot it's seems to be grate to use with a screen reader
<karlp>
(silly github posting openwrt links when it's not in openwrt's repo...)
<Tapper>
All some of the links in the mane menu are labeled twice.
<Tapper>
All tho*
<aiyion>
karlp: mostly like that, yes. one sec.
<karlp>
aiyion: I've got that for my own sunxi device with emmc, I'm not sure enough yet on whether it can be used for "everyone" though, and I don't have time t test it all.
<hell__>
Tapper: One of the most egregious things we found was a button that did not exist at all for screen readers and/or keyboard-only users.
<karlp>
aiyion: but feel free to push something like that :)
<Tapper>
hell__ wow! Thanks for getting things like that fixt.
<aiyion>
karlp: I tried to directly use uuids instead of building the partition string by hand.
<Tapper>
hell__ it's one of the things I love most about OpenWrt. Luci is a joi to use.
<karlp>
well, uuids have to come from somewhere.
<karlp>
I didn't feel it bought anything.
<Tapper>
OEM fw well don't get me started! lol
<karlp>
I won't be using it personally anyway, as I want to have uboot+env in an emmc boot partition instead
<karlp>
but that got me going nicely.
<hell__>
OEM firmware is awful in more aspects than just user interface
<aiyion>
karlp: just happy to see, others saw the same problem :)
<aiyion>
I feel like its a question of style, if both approaches work. Would you mind if I referenced your patch on the mailinglist as well?
<karlp>
there's not a lot of sunxi devices traditionally around that had emmc, so it jsut didn't come up a lot I don't think.
<aiyion>
Likely, yes.
<karlp>
go for it, it's in my pile of "this isn't ready to try and push anywhere yet"
<karlp>
some of it's also historical,
<karlp>
years ago some chromeos guys tried to get aliases to make this not ap roblem, and got yelled at with "hur, use uuids blah"
<karlp>
and nowawdays the aliases have been accepted anyway, so.. *shrugs*
<aiyion>
It's advent -the time of the year I push everything into that I should fix or evaluate "at some point int the year". So this is me reducing the size of my pile ;)
<aiyion>
I really like the `anymmc` uenv, that looks pretty clean.
<aiyion>
Thanks!
<karlp>
you're very welcome
<Tapper>
hell__ O I know mate! Some times you feel like bangging your head on your desk just trying to flash the bastard when using a screen reader.
<Tapper>
OpenWrt all the way for me now. I will never run oem.
goliath has joined #openwrt-devel
<robimarko>
So you guys dont like having to use a mobile phone with an app that calls back constantly to use your router?
<Znevna>
hm?
<robimarko>
Ok, my sarcasm was terrible
<aiyion>
Linux has/had a script that recommended people to review a patch. I'm new to sunxi, does OpenWrt have something like that too? Or do I search git log/blame for past sunxi contributors?
<karlp>
problem with partuuid IMO is that it relies on ... partitiions.
<karlp>
and you don't really have to use them,
<karlp>
I mean, if you're goign to use them, fine :)
<shibboleth>
k
shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openwrt-devel
<aiyion>
Would you mind putting that in the mailthread? I think it shoul be fine in this case, as we are already specifying mmcblk0p2 which is a partition, no?
<aiyion>
karlp: ^
<karlp>
nah, not my concern, any solution is better than none :)
<karlp>
I actually tried uuids first, and ran into issues, but i no longer remember what they were.
<karlp>
something like part uuids work, but block uuids don't, because they don't exist unti later or something silly.
<jow>
but I am still a little bit annoyed that some standard functionality broke (again) without having touched the code in question for a long time and nobody noticing it
<jow>
stintel: tbh I'd direct the feature request to dedicated forum category
<jow>
stintel: people are far more likely to receive constructive (or any) feedback there
<stintel>
makes sense
<stintel>
is there such a category ?
minimal has quit [Quit: Leaving]
<stintel>
in any case we really need to improve the issue tracker
<stintel>
it's so bloated there is no oversight anymore
<stintel>
completely loses its value like this
<stintel>
because it's kind of impossible to properly track anything
<stintel>
at my previous client we would have a wiki page for ideas
<stintel>
and move it to an issue once someone has time to pick it up
<jow>
well whenever I look into it I immediately spot a bucnh of tickets that will never go anywhere
<jow>
we should simply close those
<stintel>
I suggest we organize some issue squashing day
cmonroe has quit [Ping timeout: 480 seconds]
<jow>
yeah
<stintel>
we can use it to close a bunch of those issues and at the same time write standard responses in the wiki or so
<jow>
I've little time for coding worjk these days but I could help discussing issues in irc
<jow>
as in discussing whether to keep, close, move
<stintel>
yeah
cmonroe has joined #openwrt-devel
<stintel>
I sometimes go through the issues too, but often I'm not sure what to do
<f00b4r0>
same
<stintel>
if at that point you can discuss with just a few other people and come to a consensus ... much better
<jow>
I supose all other devs feel the same, so they're simply left alone
<jow>
and only aggregating "me toos"
<stintel>
maybe we can have the bot close things if N members post something like "DNBH *"
<jow>
and maybe also close tickets without activity in over 24 months
<stintel>
(we can come up with acronyms, this one is Does Not Belong Here"
<stintel>
similar to auto-merge on N LGTM (not relevant for us as we don't merge in github but you get the idea)
<jow>
witrh a ticket like "This issue hasn't received any attention in 2 years, it is unlikely to get acted upon at this point in time. Due to this, we decided to close this issue. If you feel that it is important or if you can provide further information, please request reopening by commenting on it."
<jow>
*erm with a response like
<f00b4r0>
stintel: imho acronym-based closing would need the bot to spell out the acronym, otherwise it may be a tad rude to users
<f00b4r0>
jow: +1
<jow>
and I think the reply above is also honest, it does not imply that the issue got fixed/adressed/investigated and clearly spells out that it wasn't tackled due to a lack of interest
<jow>
so nobody should feel deceived
<f00b4r0>
*nod*
<stintel>
f00b4r0: just thinking out loud ;)
<f00b4r0>
;)
<stintel>
but this LGTM-like approach could work async
<stintel>
and might actually encourage other devs to reply rather than "ok maybe later"
<f00b4r0>
true
<jow>
(redirecting users between the various repos is also rude, but one problem at a time)
<f00b4r0>
heh :)
<stintel>
haha I find reporting in the wrong repo rude :P
* Borromini
thought DNBH was 'don't bother, honestly'
<f00b4r0>
sounds about right ;}
<stintel>
Borromini: like I said, just thinking out loud, making things up as I go
<jow>
sometimes I tell users "this isn't a LuCI problem" and direct them to openwrt/openwrt, only to reply *there* then
<Borromini>
stintel: just yanking your chain :^)
<stintel>
:P
<f00b4r0>
would be nice if GH had a "move issue" capability
<jow>
from a user pov this likely looks like harassment
<Borromini>
Znevna: looks like it, ask nbd to be sure
<Znevna>
nah I don't bother devs because of some LEDs
<Znevna>
I'll keep digging
<Borromini>
he's in here, won't hurt to ask... or maybe someone else more knowledgeable than me can confirm
<Znevna>
i got sick of myself asking about these leds so many times :P
<dhewg>
jow: I was surprised about that part being broken for so long too, but was scanning really completely broken? there're a few other scan methods and code flows
<dhewg>
the other (purely cosmetic) issue that was broken due to ujail&perms was a mesh's encryption being shown as "none". ppl noticed that though
<jow>
dhewg: abi change is problematic, does not matter if small or big
<jow>
dhewg: at least in 22.03 we should avoid it
<dhewg>
oh that for sure, I was merely talking and aiming at master
<dhewg>
the real fixes to backport are few
<dhewg>
the socket perms one prolly the most urgent
<jow>
yes
<jow>
I am unsure if we should continue iwinfo as-is anyway
<jow>
now that most drivers are nl80211/cfg80211 we don't need an abstraction anymore, just a simplified wrapper
<jow>
LuCI being ported to ucode now can use ucode-mod-nl80211 directly
<jow>
rpcd-mod-iwinfo could be replaced with an ucode applet too
<jow>
what's left is the hardware db aspect
<dhewg>
yeah, I was wondering about that too, the current state is rather messy
<jow>
so maybe replace iwinfo the cmdline tool with an ucode script
<jow>
keep libiwinfo, but frozen
<jow>
port luci and rpcd to ucode w/ nl80211.so
<dhewg>
sounds good, but that's a bit of work
ptudor has quit [Quit: Strict-Transport-Security: max-age=48211200; preload]
<jow>
or keep iwinfo as C cli + lib but do a libiwinfo2 that only supports nl82011 and utilizies blobmsg or an equivalent flexible format
<jow>
and that does away with the fixed return buffer style api
<dhewg>
v2+blob sounds good to me, I was wondering if the lib should provide that for some consumers :)
<dhewg>
the lib and its lua binding is used by a few packages too, so I guess that needs to stay in one form or another
<jow>
I didlike the unstructured-ness of blobmsg though
<jow>
*dislike
<dhewg>
but anyway, the current state of 6g on the upper levels due to iwinfo is rather lame. Since I've done the patches anyway, pick those in one form or another and then whip up a plan for libiwinfo.so.2?
<jow>
yes
<dhewg>
it's just a couple of minor fixes, but it's already way nicer :)
<jow>
will first try latest iwinfo head on 22.03, then proceed picking your fixes
<dhewg>
sounds good, let's see what's left then :)
<dhewg>
I'm not 100% happy with the usd device id path, but the fake pci ids for ftd isn't that nice either
<dhewg>
but I guess that's all v2 material
<jow>
I noticed that hardcoded "compatible" strings crept into the code
<dhewg>
I'm not sure if that super slow scan-mtd-parts for wifi ids is required anymore?
<jow>
and I missed that entire ftd thing
<jow>
it used to be required on ath25 at least
<jow>
back when it was ar23xx
<dhewg>
hehe, I guess there's an argument about that everything could be moved to ftd ids since everything moves to ftd?
<dhewg>
right now, that slow mtd scan is done on every poll from luci
<jow>
yeah
<dhewg>
which is why I noticed that slowdown with my usb dongle in the first place
<jow>
I don't know what the state of ath25 is nowadays
<robimarko>
I think its pretty much abandonware
<jow>
the primary motivation for mtd scan was to differentiate things like fonera, nanostation 2, nanostation 5 etc.
<robimarko>
Borromini: There is a reason why nobody backported that RX filtering series
<Borromini>
robimarko: ok do tell?
<dhewg>
I also noticed that iwinfo is compiled with just the nl80211 backend, but there's boards in tree with still use wl?
<jow>
or maybe we can utilize board.json
<robimarko>
Have you looked at how huge it its?
<Borromini>
(i moved to 5.15 on 22.03 as well for mvebu...)
<jow>
or /tmp/sysinfo
<Borromini>
robimarko: ok :P
<jow>
dhewg: I'd consider "wl" unsupported
<jow>
the netifd backend is half broken
<jow>
the iwinfo backend didn't keep up with nl80211 features
<robimarko>
Everything except for nl80211 is pretty much broken
<jow>
the blob we use does not expose all the info we need
<jow>
drivers requiring wext tend to have arcane proprietary ioctl apis which we don't cover either
<jow>
and madwifi is throughly dead
<dhewg>
so let's kill all of that with fire?
<dhewg>
hehe
<jow>
there could be a theoretical need for proprietary ralink stuff but since we don't have that in the tree there's likely no need to accomodate this use case
<dhewg>
it prolly makes sense to look at the boards using wl first. If they're good to go there's quite some cleanups possible
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<robimarko>
Have we got rid of WEXT?
<robimarko>
That really is something that should go
<jow>
robimarko: I think by now, yes
<robimarko>
There are still kernel and hostapd patches for WEXT
<jow>
I think in a hypothetical sceanrio where a vendor bases his firmware on openwrt, want's to use luci as is (very unlikely) and utilizes a non-nl80211 driver, shipping a complete, api/abi compatible libiwinfo replacement talking proprietary driver apis in the background is easier
<jow>
... than maintaining half broken iwinfo backends
<olmari>
but...but... then it would not be propietary andandand... :D
<jow>
chances are high that a custom hostapd and wifi config stack is used anyway in this case
<robimarko>
I honestly couldnt care less about what vendors are doing
<jow>
since writing netifd/openwrt wireless driver backends is undocumented black art
<jow>
I think it is likely (or at least it would make sense) that openwrt loses this ability eventually and solely supports nl80211
<Borromini>
don't they tend to use ancient codebases anyway? just like with the kernels?
<olmari>
I have more than once got truly amused how vendors have taken openwrt and "we do this better" and failed miserably... not specifically some wireless thing, but all teh things...
<olmari>
Inteno's "chaos breaker" (or very similar from 2 different owrt releases) was funniest codename.. and I bet whoever was coding it knew exactly why he chose the naming...
floof58 is now known as Guest2260
floof58 has joined #openwrt-devel
<jow>
dhewg: I'm not totally happy with the usb check
<jow>
dhewg: what about reading $(readlink -f /sys/class/net/$ifname/device)/../idProduct ?
<jow>
+ idVendor
ptudor has joined #openwrt-devel
Guest2260 has quit [Ping timeout: 480 seconds]
<dhewg>
it's doing that for the ids, but I guess you mean the subsystem check?
<jow>
problem is that 0000 is theoretically a valid pci id
<jow>
ffff is not
<dhewg>
yeah, but there's a bunch of ffff ffff entries, I was picking one with less probably conflicts
<dhewg>
The proper solution would be to seperate pci from usb there
<dhewg>
but then you could seperate ftd too
<dhewg>
and then seperate those to distinct id files
<dhewg>
I guess I just drew a line somewhere, the set is already rather big
<jow>
I'd probably prepend each line with a subsystem name
<jow>
and in case a line begins with a digit, assume pci, for backwards compat
<jow>
or do a wildcard match and simply yield the first matching entry, ignoring the subsystem kind
csharper2005 has joined #openwrt-devel
<jow>
oh well, v2 material. let's go with 0000 0000 idVendor idProduct
<dhewg>
should work just fine, but yeah, if that's not good enough we should redo it 100%, and not stop half way. Like the id string vendor/product is nice, but the four ids don't make much sense for !pci
<dhewg>
and if redoing that I'd prolly tend to expose the subsystem string too
<csharper2005>
Hi, guys! I would like to create a new (supported) device page for Etisalat S3 router. Are there OpenWrt wiki admins here who can help me add a new vendor - Etisalat?
<Borromini>
csharper2005: i think you'd need to ping tmomas on the forums for that
<csharper2005>
Borromini: Thank you. I am here on their recommendation. Unfortunately, they don't have access to the wiki right now. If nobody knows how to add new brand (or has no rights) here, I'll come back to tmomas later.
<Borromini>
PaulFertser can create wiki accounts but I doubt he can add brands
schwicht has joined #openwrt-devel
<mrnuke>
svanheule_: 5.15 for realtek!!! Thank you for getting the merge completed!
<csharper2005>
Looking forward to 5.15 on ramips! :)
<dhewg>
jow: yeah, I think you're right, I probably meant >=2
Mangix has quit []
Mangix has joined #openwrt-devel
<jow>
dhewg: I applied most of the series
<jow>
I am not entirely happy about the change from NOHT to 20
<jow>
right now the cli prints "HT Mode: 20"
<jow>
in the absence of any other HT radio (which would print "HT Mode: HT20") one could easily confuse the above with "operates in HT20 mode"
<dhewg>
we can leave it at NOHT, these changes came from not wanting to change the ubus output while converting them from hardcoded lists to loops and reusing the iwinfo strings
<dhewg>
same with those two wep dashes, but those are harmless
<dhewg>
I was carefully diffing ubus output :)
<jow>
hm, yeah I understand
<jow>
not really happy with "htmode": "20" either
<jow>
given that the other modes are also strings we maybe should just change it to "none"
<jow>
I backed out the change for now, we can reapply it later
<dhewg>
yeah, sounds good. Maybe it doesn't even matter