Discussion: stop sftp package uploads

[Brian Inglis]

On 2025-07-02 15:06, Jon Turney via Cygwin-apps wrote:
> 
> So, to follow on from the points raised in the thread ending [1], and perhaps 
> start a discussion:
> Having developers build executable packages locally and then upload them doesn't 
> really meet contemporary standards.
> Given my druthers, I'd just disable sftp package uploads right now, and make you 
> all use the janky "build service" I hacked together in a few spare weekends.
> Amongst the advantages this has:
> * Ensures that the packaging git repo is updated when the package is.
> * Ensures that the source package is complete; and that the build works and is 
> repeatable.
> * Ensures that the package is built in a sterile environment.
> * Ensures that the package is serially developed in the git main branch (so when 
> someone does a NMU, they don't also need to remember to explicitly communicate 
> any changes made to the maintainer so they don't drop off again in the next 
> release...)
> * Transparency about, and some degree of auditability on how, the contents of 
> the install package are generated.
> * The way we provide a chrooted sftp session for uploads is weird and non- 
> standard and this means sourceware no longer has to support it.
> (A related consideration is that this probably also helps if/when we want to 
> start providing arm64 packages (which will otherwise entail all the problems we 
> had when x86_64 started being a thing - but at least in that case, most 
> maintainers had the necessary hardware, if not the needed OS) - The alternative 
> seems to be providing numerous cross-build packages, which doesn't seem like a 
> good use of anyone's time...)
> Unfortunately, there are some issues with my half-assed replacement:
> * It relies on free CI services (GitHub and AppVeyor) to do the actual builds, 
> which might be withdrawn or start charging.
> * In particular, github requires an account to view the logs, which is a 
> sticking point for some people.
> * There's a number of problems with the current implementation: For a start it's 
> a synchronous daisy-chain of actions, which isn't tolerant of intermittent 
> connectivity or other transient problems.
> * The "tokens" which can specified to control options in it are an ad-hoc mess. 
> Idk what the ideal solution is, but the names of those options all need 
> rethinking for a start...
> * If you want to rebuild A and then B which requires the new B, you have to 
> guess when to submit the build for B. (perhaps it needs private access to the 
> repo rather than using a mirror, to ensure the copy it's looking at is up to 
> date, but even then...)
> * Some packages have circular dependencies, requiring some bootstrapping build 
> of package A, using that to build B, before returning to rebuild package A 
> properly with B available. This is completely unaccounted for in the current 
> model of doing things.
> * There are a couple of packagers using their own handcrafted packaging rather 
> than cygport.
> I'll be reaching out the those soon to discuss what can (reasonably) be done to 
> accommodate them.
> Any questions/thoughts/concerns?
> [1] https://cygwin.com/pipermail/cygwin-apps/2025-June/044388.html

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/VMs added, and 
Scallywag running under those, getting off the GitHub and Appveyor servers?

Under the Mission web page they do say "others - just ask!" so should we?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry