You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The below is extracted from the logs, the main dnf step takes 2,038 seconds (34 minutes).
Notably, no output is produced for ~12 minutes (730 seconds). "Fedora 40 - aarch64 - Updates" then takes another 6 minutes (370 seconds). In the second builddep command, another six minutes (350 seconds) elapse from "enabling fedora-source repository" to the first "Package [...] is already installed.".
Notably, no output is produced for ~12 minutes (730 seconds). "Fedora 40 - aarch64 - Updates" then takes another 6 minutes (370 seconds). In the second builddep command, another six minutes (350 seconds) elapse from "enabling fedora-source repository" to the first "Package [...] is already installed.".
That's pretty bad, but I have no idea why would it take so long. Perhaps it's the emulation/virtualization that is there that is so slow?
FYI, 3 mins running releases were about Autoconf :)
For the devcontainer it takes a long time, but thanks to your comment, I've written up a new PR for distinguishing which packages were released :)
What do you think about splitting actual container creation into two steps? One with big dnf steps, which rarely changes. And another container with all other steps. Unfortunately, we should use some sort of links to actual containers. But regular updates can be much faster with this scheme.
I'm personally fine with that if @corona10 and @erlend-aasland are. I have #12 open to split things up in regards to WASI, but I wasn't sure about following through with it due to having to change the CPython repo when new containers go out. We might need to settle on some policy in #11 to know how much work would be expected.
Based on the last release run for the dev container, this is now down to under 11 minutes, which seems reasonable to me, so I'm going to close this issue.
Activity
AA-Turner commentedon Sep 26, 2024
The below is extracted from the logs, the main
dnfstep takes 2,038 seconds (34 minutes).Notably, no output is produced for ~12 minutes (730 seconds). "Fedora 40 - aarch64 - Updates" then takes another 6 minutes (370 seconds). In the second
builddepcommand, another six minutes (350 seconds) elapse from "enabling fedora-source repository" to the first "Package [...] is already installed.".cc @hroncok for any advice (as author of python/cpython#103283)
dnf install ...:dnf builddep python3:dnf clean:hroncok commentedon Sep 26, 2024
That's pretty bad, but I have no idea why would it take so long. Perhaps it's the emulation/virtualization that is there that is so slow?
trallard commentedon Oct 7, 2024
I was having a quick nosey here 👋🏽 but looking at the Actions runs, the build is taking
< 3minsand the 35 mins + was an outlier.Update to Fedora 41 with dnf5
Disable extra repository with a multimedia codec
Possible speedups (#15)
corona10 commentedon Oct 8, 2024
@trallard
FYI, 3 mins running releases were about Autoconf :)
For the devcontainer it takes a long time, but thanks to your comment, I've written up a new PR for distinguishing which packages were released :)
Please take a look if you are interested :)
#16
trallard commentedon Oct 8, 2024
Ah that makes sense. Will have a look over there and maybe do some digging on why this is taking so long then.
corona10 commentedon Oct 9, 2024
Last release by Brett took 28 mins.
(36mins -> 28mins!!)
https://github.com/python/cpython-devcontainers/actions/runs/11245912749
The PR by @hroncok enhanced the speed a lot!
hroncok commentedon Oct 10, 2024
We have a container job at github actions that runs dnf on 4 architectures. The arm64 one (third in the screenshot) is regularly extremely slow:
efimov-mikhail commentedon Nov 24, 2024
What do you think about splitting actual container creation into two steps? One with big
dnfsteps, which rarely changes. And another container with all other steps. Unfortunately, we should use some sort of links to actual containers. But regular updates can be much faster with this scheme.brettcannon commentedon Nov 25, 2024
I'm personally fine with that if @corona10 and @erlend-aasland are. I have #12 open to split things up in regards to WASI, but I wasn't sure about following through with it due to having to change the CPython repo when new containers go out. We might need to settle on some policy in #11 to know how much work would be expected.
erlend-aasland commentedon Nov 25, 2024
+1
corona10 commentedon Nov 26, 2024
+1
brettcannon commentedon Nov 17, 2025
Based on the last release run for the dev container, this is now down to under 11 minutes, which seems reasonable to me, so I'm going to close this issue.