<pivi>
they might be all different issues, or maybe not, they started to appear out of the blue in the last week or so
<pivi>
(and no, I have not being able to bi-sect any of this yet, just trying to figure out if this is known to someone)
___nick___ has joined #u-boot
ikarso has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
f_[x] has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #u-boot
ellyq has quit [Quit: WeeChat 4.2.2]
ellyq has joined #u-boot
mckoan is now known as mckoan|away
akaWolf has joined #u-boot
<sjg1>
Tartarus: How long does a full CI run take with your new series? Also, do you have instructions as to what runner tags should be used for which runners?
naoki has quit [Quit: naoki]
gsz has joined #u-boot
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #u-boot
eballetbo has joined #u-boot
prabhakalad has quit [Ping timeout: 265 seconds]
prabhakalad has joined #u-boot
<Tartarus>
sjg1: About as long as before, but more consistently now that the slowest job is the world build, which tops out at around 40-45min
<Tartarus>
And I've updated all of the shared runners, I think I can edit the tree-specific ones, but it should also generally be clear (everyone gets all, all amd64 get amd64, only fast amd64 should get fast amd64, all arm64 gets arm64)
<Tartarus>
pivi: I don't know, I boot my am62 from SD card
<Tartarus>
(evm and beagleplay)
<sjg1>
Tartarus: OK, here are my thoughts:
<sjg1>
1. We should run the QEMU jobs in parallel (on fast machines). Each fast runner can pick up 10 jobs
ldevulder has quit [Quit: Leaving]
<sjg1>
2. We should set an overall target for CI time. Currently it is 35mins for my CI, I'd like to get it down to 20mins
<sjg1>
3. So I worry that having a 40-45min job is not heading in the right direction
Clamor has joined #u-boot
<sjg1>
Tartarus: Perhaps buildman could support grouping boards by set, e.g. 250 in each set?
pericycle has quit [Ping timeout: 248 seconds]
<Tartarus>
You are free to add more runners to the "all" tag, which will speed up that stage.
<Tartarus>
If we drop "fast amd64" from kaka, and introduce "fast arm64", and I think don't tag alexandra, it's more like a 20min job?
mmu_man has joined #u-boot
<Tartarus>
The real problem is that we lack more than 1 or 2 actually fast builders of each host architecture
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #u-boot
<sjg1>
Yes, kaka is more 'medium' than fast, only tui and moa are fast
<sjg1>
Tartarus: I don't mean more runners, I mean setting the 'limit' to 10 for a particular runner, for QEMU jobs only. So we need a tag for QEMU jobs
<Clamor>
Are there helpers which allow parsing port nodes? Like those used in linux panels/bridges.
<sjg1>
It consistently runs in 35mins, if it is the only pipeline running
<Tartarus>
Yes, I don't think that's worth the complexity, the long pole is almost always the sandbox jobs since those take 10min or more and we clear out the rest of the qemu ones quickly
<Tartarus>
We could matrix the world build, still as 4 jobs, but I'm not sure that will be a win since we'll be bottle necked by having 2 fast runners of each architecture
<sjg1>
Tartarus: OK, so I mean all the test.py jobs, not just QEMU. They can run in parallel on fast machines. The entire test.py stage takes about 5mins for me, although I haven't timed it accurately
<Tartarus>
Maybe we're saying the same thing then?
pericycle has joined #u-boot
<sjg1>
Maybe. Once your stuff lands and runners are updated, we can compare approaches and refine
<Tartarus>
But let me say I'm not happy you're putting your personal CI up as "ci.u-boot.org", the official CI is the denx one, and it'd be good to just CNAME ci.u-boot.org to that, or do a redirect to https://source.denx.de/u-boot/
goliath has quit [Quit: SIGSEGV]
<sjg1>
I'm not happy about it either, but I believe that is where we have landed, for now, unfortunately
<Tartarus>
I would prefer if you named it "sjg.u-boot.org" or similar, so that it's clear it's your tree and not the official tree, to avoid confusion.
<apalos>
q
<apalos>
sjg1: I really don't understand what you've been doing lately tbh
<apalos>
Replying to patches "Applied to ci/master" and confusing people patches are accepted
<apalos>
setting up a CNAME identical to the official u-boot
<apalos>
I think this is going nowhere, because the next step is send a patch saying
<apalos>
"Ignore ci.u-boot.org, it's not in the official project"
<apalos>
It's a CNAME you can name it whatever you like, so is there *any* reasoble explanation for the CNAME you choose?
<apalos>
reasonable*
frieder has quit [Remote host closed the connection]
<sjg1>
Tartarus: Sure, I don't mind what it is called
<Tartarus>
sjg1: Thanks.
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
urja has quit [Read error: Connection reset by peer]
urja has joined #u-boot
goliath has quit [Quit: SIGSEGV]
joeskb7 has joined #u-boot
monstr has quit [Remote host closed the connection]
zumbi has joined #u-boot
vagrantc has joined #u-boot
goliath has joined #u-boot
naoki has joined #u-boot
<Tartarus>
sjg1: I think long term we need less "default y if SANDBOX" for arbitrary commands so that they're tested and more use of sandbox variants #include sandbox_defconfig and then tweak things as needed, with the defconfig enabling stuff.
<Tartarus>
I'm not replying to the series you sent on top of mjg's series because there's still more fundamental changes like that addr command shouldn't be added at all and instead we do more like mach-apple does for "find me a range" needs
cbeznea has quit [Ping timeout: 244 seconds]
___nick___ has quit [Ping timeout: 248 seconds]
alexxy has quit [Ping timeout: 246 seconds]
MyNetAz has quit [Read error: Connection reset by peer]
MyNetAz has quit [Remote host closed the connection]
slobodan has quit [Ping timeout: 244 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
MyNetAz has joined #u-boot
paulhenrys has quit [Read error: Connection reset by peer]
ikarso has joined #u-boot
MyNetAz has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 252 seconds]
<sjg1>
Tartarus: We should have default y anyway, since we mostly require a sandbox test for each new command/subcommand
<sjg1>
Re the EFI-app, it's OK. I'll apply it to my tree and carry on. At some point I'll get to where you want to be (will be several more series at least, perhaps aiming for Feb'25) and then we can figure out how to line things up
<sjg1>
I need it for the PXE EFI stuff I'm trying to get going on rpi, so I suppose I'll pull that in as well. Ilias reviewed one patch but I haven't seen any other comments
<Tartarus>
sjg1: I don't think adding lots of "default y if sandbox" is right, we should just use "allyesconfig" for sandbox when needed in that case
<Tartarus>
sjg1: And re EFI-app, yes, I hope you don't end up missing what calebccff is also doing with their postmarketOS hat on
<sjg1>
I don't mind either way. What is Caleb doing?
<Tartarus>
And for that series, were you going to re-post it with efi_loader so it's not otherwise missed, or just pick up Ilias' tag and then take it for your own future queue
<Tartarus>
And Caleb posted an EFI app series, as RFC, like a day before mjg's series, I think, that added arm64 support for EFI app, but needed some other cleanups too, hence the RFC
<sjg1>
I'll just take it...I looked at MAINTAINERS and Ilias is maintainer for lib/efi*/
goliath has quit [Quit: SIGSEGV]
<sjg1>
For patches since then I've been using an efi_loader: tag
mmu_man has joined #u-boot
<sjg1>
Tartarus: Oh and I see Peter in unhappy again
prabhakalad has quit [Remote host closed the connection]
<Tartarus>
sjg1: Yes, and he's also right, you do need to wait a bit longer between reposting things
prabhakalad has joined #u-boot
<sjg1>
A bit longer, or a week?
<sjg1>
Oh the EFI series just changed to 'deferred'?
<Tartarus>
Well, 3 times in less than 24h is too much. Some number of days would be better, especially when you need to test things
<Tartarus>
Yes, I changed that to you and deferred, I'm assuming you'll pick it up from wherever you have it stashed
MyNetAz has joined #u-boot
<sjg1>
Tartarus: OK. At least this way we have things the way you want them and Peter only needs to look at the final version, if he has time
<sjg1>
Re Caleb's thing, I noticed it, but it was RFC and didn't really have a comment. I suppose he will post an official version at some point
<sjg1>
Quite telling that it needs to use the EFI stub instead of app :-(
<Tartarus>
I mean, an RFC version is an official version? And I thought it got some feedback as well.
<Tartarus>
And please note that "what hardware did you test this on" is an important question to resolve, along with mine about confirming that overlays are still working
<sjg1>
OK, sure. It looks fine to me, but it would be better to reduce the amount of duplicated code now rather than later
<Tartarus>
Yes, I was hoping that calebccff and mjg would end up working on something together, but you've gone and pulled mjg's version of things to your tree instead
<Tartarus>
And no, I don't know what people will do next with that.
<sjg1>
Does Peter have an automated lab? When I spoke to him it seemed like testing was mostly a manual affair
<sjg1>
No, they are different things, one is the app and the other is the payload
<sjg1>
It is the app that is particularly interesting to me, TBD
<sjg1>
TBH :-)
<sjg1>
Tartarus: Re the EFI patches, no I am not picking those up. Strictly speaking I am maintainer for EFI app, not EFI_LOADER
<sjg1>
Tartarus: I'll bring them into my tree though
mmu_man has quit [Ping timeout: 265 seconds]
<naoki>
After make all, I can see "binman-fake/" under "Untracked files:" in git status. Should it be .gitignore-ed directory?
<naoki>
There are empty "atf-bl31 rockchip-tpltee-os" files