<karlp>
I guess it's kinda intending to make blah > wop have spaces right
<karlp>
personally, I feel like replacing "blah && [literal new line] more code" with "blah \ [literal new line] && more code" seems like a step backwards,
<karlp>
vast majority of it looks pretty fine though :)
<karlp>
you've got a style setting that is causing the case's to be indented?
<aparcar[m]>
curious why is that a backstep? it helps to understand that a line you read is dependend on the previous line
<aparcar[m]>
yes that's an extra setting
<karlp>
that seems like a waste of space, and linux at least normall puts cases on the same line as the switch
<aparcar[m]>
-ci switch cases will be indented
<karlp>
I've seen too many bugs from unintentional \ continuations
<karlp>
the indent is already there, it's already correct, adding \ doesn't make it easier to read (code or console output) or copy IMO.
<karlp>
but whatevs, it's just autolinitng, it can kinda be whatever.
<aparcar[m]>
karlp: I'm happy to change the options as long as we have something everyone follows (and mostly agrees with ;))
<karlp>
the services and protocols files kidna feel like they should be excluded?
<karlp>
they're not shell scripts...
<aparcar[m]>
the lint-hammer works on them just fine
<karlp>
yes, but should it :)
<karlp>
anyway, I'm just up late and don't work on this stuff normally anyway :)
<aparcar[m]>
I'm happy for the comments, thanks
<karlp>
the json_select indenting is... I know not "correct" but I think it has often been done intentially, to show the depth changes that json_select is actually performing
<karlp>
you're.... totally correct, and it makes it auto"fixable" but it kinda is losing useful information there, except it's information that has to be manually kept up to date of course....
<aparcar[m]>
yea I'll wait for comments there don't really like that and would rather work with comments around that...
<karlp>
yeah, comments to turn off linting are also gross as hell.
<karlp>
anyway, it's late. definitely not time for a coffee ;)
* karlp
waves
<aparcar[m]>
no I mean comments like in makefile, where it's endef # foobar
<aparcar[m]>
byee
JohnA_ has joined #openwrt-devel
JohnA has quit [Ping timeout: 480 seconds]
Weasel___ has quit [Read error: Connection reset by peer]
Weasel___ has joined #openwrt-devel
<mangix>
aparcar[m]: looks great. the -EOF thing is weird. same with it adding to &&.
<mangix>
sounds like it should just be moved to 1 line
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<aparcar[m]>
mangix: hrm I don't see what's the issue there, please comment on the code directly that concerns you.
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
JohnA_ has quit [Quit: Leaving]
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
swalker has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
dangole has quit [Ping timeout: 480 seconds]
rmilecki has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
m has joined #openwrt-devel
mcarroll76 has quit [Remote host closed the connection]
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Weasel___ has joined #openwrt-devel
Guest217 has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<jow>
Strykar: good idea, but won't have any time soon to work on it
<jow>
hauke: afair there was one further report somewhere i nthe forum, but can't find it atm
<jow>
nbd: can we reconsider that implicit vlan magic when attaching wireless networks to interfaces?
<jow>
nbd: having a wifi iface somehow inherit vlan ID X just because the destination interface happens to reference a bridge.X as device is very counter intuitive
<jow>
it also extremely complicates ui logic
<jow>
also what happens if the target device is a double tagged bridge? does the automagic behaviour apply as well then?
<hauke>
aparcar[m]: mangix: I plan to support 19.07 for about 6 months after the 21.02 release, currently it is still supported and we should do a new minor release soon
<hauke>
rsalvaterra_: I agree with you that it is unlikly caused by the kernel update
<rsalvaterra_>
hauke: Speaking of which, .46 is out, I'm taking care of it now. :)
<digitalcircuit>
My guess would be waiting (folks are understandably busy), and attempting to find a stress-ng reproducer (admittedly the number of options for it are a bit overwhelming considering how several attempts so far have resulted in new/seemingly unrelated kernel panics).
<nbd>
i thought when we last discussed this, we agreed to simplify the UI by simply letting the user choose a network for a wifi device
<nbd>
and leaving it up to the user to make a sane decision
<nbd>
and if we add a wifi vif to a vlan enabled bridge, hostapd needs to know about the bridge.X device (or any other name under which it may be operating) anyway
<nbd>
if we only add the bridge name and the vlan id, that would mean i would have to add more magic in the other direction in netifd to check if there is an explicitly or implicitly created vlan device on top
<nbd>
and look up the name and pass it to hostapd
<nbd>
(for 802.11r at least)
ashkan has joined #openwrt-devel
aleasto has quit [Remote host closed the connection]
dedeckeh has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<hauke>
digitalcircuit: It would be nice if Ansuel could ack it
Borromini has quit [Quit: Lost terminal]
<digitalcircuit>
hauke: Understood, and agreed - getting feedback from the one who made the change would reassure I'm not doing anything terribly wrong :)
dorf_ has joined #openwrt-devel
<Strykar>
jow: aw :/
feriman has joined #openwrt-devel
<nbd>
jow: i think regarding double tagging, there might be a bug there
<nbd>
easy to fix though
<nbd>
never mind, there is no bug there
<nbd>
this behavior only applies if the underlying device has bridge vlan devices defined
feriman has quit [Quit: WeeChat 3.2]
SamantazFox is now known as Guest355
SamantazFox has joined #openwrt-devel
Guest355 has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
PaulFertser has quit [Ping timeout: 480 seconds]
PaulFertser has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
<rsalvaterra>
hauke: Pull updated, now at 5.10.46.
Rentong has quit [Ping timeout: 480 seconds]
ashkan has quit [Ping timeout: 480 seconds]
dorf_ has quit [Remote host closed the connection]
<mangix>
aparcar[m]: I responded on the mailing listr
<aparcar[m]>
thanks
<aparcar[m]>
mangix: so you start up the machine, it set's TZ automatically to UTC, you change zoneinfo to whereever you are, /etc/init.d/system reaster > /tmp/TZ is still there
<aparcar[m]>
reboot > okay now it works
<aparcar[m]>
but essentially a reload/restart of the system service doesn't fix it
<aparcar[m]>
which is an issue
<mangix>
aparcar[m]: uhh, what?
<mangix>
people upgrading openwrt absolutely must reboot
<aparcar[m]>
I responded via email
<aparcar[m]>
crossfire
Rentong has joined #openwrt-devel
<mangix>
I'll post it on GitHub. I'm not subscribed to the mailing list
wb9688 has quit [Ping timeout: 480 seconds]
Rentong has quit [Ping timeout: 480 seconds]
<aparcar[m]>
you are WHAT
<aparcar[m]>
not subscribed to devel
<aparcar[m]>
mangix: anyway ping me once you created something on gh