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
