This branch also includes the fix for fetch-kde-qt.sh from #104684. (But this could be omitted, fit the "new" approach of downloading and hashing the archives is deemed more suitable)

What are the advantages of extracting the file hashes from HTML instead of hashing the downloaded files? I want to be sure the additional complexity is justified.

This branch also includes the fix for fetch-kde-qt.sh from #104684. (But this could be omitted, if the "new" approach of downloading and hashing the archives is deemed more suitable)

What are the advantages of extracting the file hashes from HTML instead of hashing the downloaded files? I want to be sure the additional complexity is justified.

Basically it's just reduced load on the servers and not having to fetch the files before they're actually needed. And of course it's a way to actually validate the downloaded archive matches what the qt or kde team intended to provide.
So, still.. maybe it's not necessary.

Before this PR becomes a non-Draft, I'll cherry-pick some changes for kinfocenter (it finally works!) from https://github.com/hamburger1984/nixpkgs/commits/kde-plasma-fixes-unstable.

Regd kinfocenter: #107781

Regd kinfocenter: #107781

Proposed my fixes in that PR.

Regarding the fetch-kde-qt.sh script:
I reverted and tried to fetch srcs.nix for kde-frameworks, kde-applications, qt-5 and plasma5

• it's slow to fetch all source packages (some mirrors are probably doing some ratelimiting..)
• the hashes calculated by the previous script don't match the ones provided on the websites (is that just a different encoding of the same hash?)

for example:

I'll include the revert and re-generated srcs.nix anyhow as my proposed script doesn't seem to gain too much love here ;-)

the hashes calculated by the previous script don't match the ones provided on the websites (is that just a different encoding of the same hash?)

Yes, this is just an encoding issue. The upstream websites undoubtedly list the SHA256 hashes in the conventional hexadecimal (base-16) notation, but all the Nix tools use base-32 (compact, but idiosyncratic).

the hashes calculated by the previous script don't match the ones provided on the websites (is that just a different encoding of the same hash?)

Yes, this is just an encoding issue. The upstream websites undoubtedly list the SHA256 hashes in the conventional hexadecimal (base-16) notation, but all the Nix tools use base-32 (compact, but idiosyncratic).

Okay. Then my script really would just improve the speed of generating srcs.nix. This does not justify the complexity, as this is not done that often, I guess.

@ttuegel any objections towards rebasing this branch on latest staging?
Also: is this form of PR fine or should I split this into more fine grained PRs?

The upstream fetch-kde-qt.sh was broken for me, so I wrote this: https://gist.github.com/CrystalGamma/c6a7252219b44cf2c6ddaf5e4c49b6da .
If you're interested, feel free to integrate it; first command line argument is the mirror to fetch the hashes from, second is the path on each of the mirrors, which is written to the srcs.nix, third is the path to the srcs.nix to write to.