<Christophe[m]1>
oh ooh. please ignore my question
schwicht has quit [Ping timeout: 480 seconds]
<\x>
Ansuel: im having issues with ipq40xx and PR 12904, its like a non VHT capable client can connect and auth and a capable one cant, hella weird, but sure, iwinfo phyX ht does show VHT20 and VHT40 now
cmonroe has quit [Ping timeout: 480 seconds]
<\x>
and surely, AP is up and shows up as VHT capable
<\x>
happens with both ath10k and ath10k-ct
<\x>
im just gonna roll back, im not competent enough to know and see whats wrong
danitool has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
<russell-->
svanheule: i have a eap225-outdoor v1 in front of me with vendor fw v5.0.5, not taking either my custom built openwrt or v5.0.3, any suggestions?
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit []
<hauke>
Slimey: please rebase your pull request to remove the merge commits
schwicht has joined #openwrt-devel
<robimarko>
ynezz: Is it still required to restart buildbot in order to pickup target changes?
schwicht has quit []
<f00b4r0>
robimarko: yes.
<f00b4r0>
(if by "target changes" you mean new (sub)targets)
<Ansuel>
ipq807x got ranamed and a new subtarget introduced
<Ansuel>
by i wonder why this limitation?
<Ansuel>
can't the master refresh them once in a while?
<f00b4r0>
Ansuel: because the buildmaster parses the output of ./scripts/dump-target-info.pl at startup to build the list of builders.
<f00b4r0>
(i'm speaking about phase1 only here of course, since that's the one I know like the back of my hand :)
<f00b4r0>
the list of builder is fixed for the execution time of the buildmaster, buildbot doesn't provide for dynamic change in builders iirc; and even if it could be done the script takes forever to execute
<f00b4r0>
so you really don't want to run it too often.
<Ansuel>
what scripts takes forever ?
<f00b4r0>
dump-target-info.pl
<Ansuel>
we use that for every run of CI
<f00b4r0>
and maybe that's why you're running out of credits ;)
<f00b4r0>
regardless, new targets isn't exactly a frequent occurence and ideally there should be less, not more, of them :)
<Ansuel>
it's just 9 seconds...
<f00b4r0>
'./scripts/dump-target-info.pl', 'targets' is *not* 9 seconds;
<f00b4r0>
and again, I don't see the point in optimizing something that by nature should be a rare occurence.
<Ansuel>
my idea would be something like a scheduled task that runs once in a while (daily? every 3 days??) and just refresh them?
<f00b4r0>
<f00b4r0> the list of builder is fixed for the execution time of the buildmaster, buildbot doesn't provide for dynamic change in builders iirc;
<Ansuel>
ok so it's a limitation as they can't be dynamic and added on a running master and master needs to be rebooted... hoped there was a chance to have that dynamic/a way to refresh it on the fly
<f00b4r0>
there isn't (to my knowledge)
<robimarko>
Ok, I hoped it got changed recently
<Ansuel>
anyway the concern was to remove the need to always ask some buildbot admin to reboot the thing, it's a rare occurence but this can happen also when new targets are introduced... with ipq807x at times it took almost 4 days for buildbot to be restarted and it's not a problem of buildbot adming since they can totally be busy and not having time, that was the idea of the need of something like that
<f00b4r0>
I disagree with your assessment :)
<Ansuel>
anyway I still don't get why that perl script is that heavy
<Ansuel>
it does call multiple make with DUMP
<f00b4r0>
Ansuel: btw try running it from a fresh checkout (I suspect most of the data was in cache).
<Ansuel>
but there is definetly a bottleneck somewhere
<Ansuel>
let me try
<Ansuel>
i bet it's the checking every package and target
<f00b4r0>
I just did from a 2016 MBP with SSD it ran in 25s