I have been hacking on getting a specific SDDM theme working, which has dependencies on KDE Plasma components. I personally do not run KDE on Funtoo. Nevertheless I embarked on installing kde-frameworks/plasma and discovered something lurking in our kde5 eclass: FTP tarball downloads and tons of HTTP 404 failures against bogus mirrors!

Long story short the kde5 eclass is auto-deriving the SRC_URI for kde-framework components here: https://code.funtoo.org/bitbucket/projects/CORE/repos/kit-fixups/browse/core-kit/curated/eclass/kde5.eclass#313-354

Unfortunately, what this is doing is trying some archaic KDE http and ftp mirrors, which is causing portage wgets of these tarballs to completely fail or time out or retry, in turn slowing emerge fetches down enormously.

How slow? On a uncapped gigabit fiber connection it took over 23 minutes to download 10MB of kde-frameworks tarballs. This is mind boggling inefficient and it is all because of the FTP site. It is so slow that even though I have the parallel-fetch portage on, emerges are going sequentially because wgets are taking so long or failing or retrying so many times.

Some emerge logs to illustrate:

>>> Emerging (21 of 21) kde-frameworks/plasma-5.94.0::kde-kit
>>> Installing (21 of 21) kde-frameworks/plasma-5.94.0::kde-kit
>>> Jobs: 21 of 21 complete                        
real    23m40.513s
user    30m58.502s
sys    2m50.787s

Emerge fetch log with all type of fun mirror attempts: kde-frameworks-emerge-fetch-slow.log

I think the kde5.eclass needs to be scraped all together and we need to migrate to something more reliable and geographically aware when selecting the site to download KDE artifacts. I found that Gentoo upstream is actually using a new eclass: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/kde.org.eclass , which seems sensible as it uses HTTPS endpoints.