On Sat, 16 Aug 2025, Jon Turney via Cygwin-apps wrote: > On 03/07/2025 01:01, Brian Inglis via Cygwin-apps wrote: > > On 2025-07-02 15:06, Jon Turney via Cygwin-apps wrote: > [...]> I have often thought why are we not leveraging Sourceware > Infrastructure > > Services and/or SFC Services more? > > > > Does Sourceware Infrastructure support any BuildBots with Windows builders > > for other (GNU?) projects, or could we get Windows containers/ > > No, these things don't exist presently, or we would be using them! > > > VMs added, and Scallywag running under those, getting off the GitHub and > > Appveyor servers? > > Certainly, a small and worthwhile initial task would be to replicate our > existing Fedora cross-build CI (which predates builder.sourceware.org) in > buildbot. > > But unless someone volunteers to do that, this just seems like the peanut > gallery inventing more work for me to do. > > > Under the Mission web page they do say "others - just ask!" so should we? > > One can ask, but the answer isn't always going to be "yes". > > Previous discussion I have on this topic have ended up with "why don't you > just run it all under wine" which was slightly frustrating to deal with. > > Of course, if someone wants to donate the services of a Windows-hosted runner, > that would be a different matter...
I'll weigh in here with my Windows-on-ARM observations. 1) technical Windows-on-ARM runs pretty well in KVM/QEMU. I figured this would translate well to https://osuosl.org/services/aarch64/. Unfortunately, Windows-on-ARM needs some different virtual hardware configuration that was somewhat new to be added to libvirt, and at the time was still not hooked up to be configurable in openstack. I had a couple of patches around somewhere to openstack to let it run Windows-on-ARM, but I don't think they ever got submitted upstream. I can try to dig them up and provide them if anyone's interested. It was also possible to run Windows-on-ARM in AWS "metal" ec2 instances (running Linux KVM/QEMU) (nested virtualization on ARM64 didn't seen to be possible yet). These instances were too big and expensive to be practical for me (I could run like 16 Windows VMs on such an instance comfortably). Microsoft Azure has support for Windows-on-ARM instances, you just have to check a box that you have the necessary license to run it (which brings up the next point) 2) licensing This is where it got difficult. Windows-on-ARM is so far only available as "client" Windows SKUs. These are not generally allowed to be run in cloud environments, but certain enterprise-type licensing schemes allow this. Also, client licenses don't allow for hosting services over the network for other users (ie, running servers). For MSYS2, I ended up getting a Windows Dev Kit 2023 provided by Microsoft, and registered self-hosted github runners in an organization in which I was the only member. This allowed me to justify to myself that I wasn't providing the runner to others, even though it built things and made the results available to others. This was in hair-splitting territory, but was necessary until GitHub started providing windows-11-arm runners themselves that MSYS2 could use.
