"F-Droid, started in 2010, still building on the same CPU" would be our anti-planned obsolescence imaginary campaign motto 😄

Jokes aside, we can't ask you to star https://issuetracker.google.com/issues/438515318 (and have its priority raised) but we can't stop you either. 😉

@fdroidorg serious question: would funding for a new set of build servers help you? I'll be very honest, and "our compile servers are so old that they don't support SSE 4.1" is not the flex in sustainability your trying to make it sound. What are these? Opterons from pre-x86_64v2 days?

@fdroidorg well it's assigned now :)

@fdroidorg may be time to upgrade to a 12-year old CPU

@znoteer I remember it like yesterday, you star it if you care, just like one does on Google Buzz, right? Oh wait, I meant Google+

😀

@fdroidorg We have to put a lot of trust in a couple of systems: the signing server and the production buildserver. That is why they are not easy to upgrade. That provides key benefits down the line, like knowing that the client app will always receive uncompromised files, no matter where it downloads the files from (e.g. verification via the signed index). Thanks for your patience while we work in getting new hardware into our trusted #secure #maintenance setup. 1/2

@fdroidorg #ReproducibleBuilds helps a lot here, that is our long term plan. Then we do not have to trust the buildserver as much. The majority of apps on F-Droid can now be built reproducibly, but many important ones still cannot. So we still need the same setup with high security requirements.

@fdroidorg as a workaround, what about spinning up a VM with emulation that supports what's missing? Sure it's slower but it should be plausible and could provide needed security fixes for affected apps.
Of course this only makes sense if the time until the servers can be replaced is long enough to make the effort of setting up the VM worth it.