Riccardo Mottola <[email protected]> writes: > Greg Troxel wrote: >> Riccardo Mottola <[email protected]> writes: >> >> They were woefully out of date, and we have a policy of only the last >> three branches for a slow arch (and 2 for one that can be built in >> reasonable time) on the ftp server, because it has finite space, and >> running out of space causes all sorts of problems. Generally, contents >> of the ftp server are copied to archive.netbsd.org and are available >> there. > > Ok.. I see... on the other hand it would be fine just keeping "last > two builds" if no new build is there.
Long ago we arrived at a plan for what can be kept as part of a plan to routinely have enough space for new builds, and it is "current and previous quarters, and for slow architectures, the previous previous can stay until the current is done". Keeping free disk space is a problem as old as disks -- I remember serious issues on a shared system in the early 80s -- and it requires a lot of manual effort, which is also in short supply. Everybody wants free space but most want to make exceptions and those two just don't go together. Hence an articulation of rules, to avoid having to have these sorts of discussions repeatedly. And, the creation of archive, to hold bits that are in general marginally useful, which couldn't possibly fit on the main server. See: https://www.pkgsrc.org/quarterly/ "Current vs. old binary package sets" As I said the real issue for sparc is that nobody is creating up-to-date builds. >> The larger issue is that nobody within TNF seems to have been doing >> pkgsrc builds for sparc since the end of 2024. There's only so much >> data center space and electricity available to the people that do this >> as a community service. Builds take more than 3 months of full-tilt >> computing. > > Understandable, on the other hand, externals cannot contribute to > building for security reasons. So it is not an easy situation. > Also consider that especially on more limited systems (almost 32bit > systems) building can be an issue. Memory can be a constraint, so > binary packages are "vital" for a useful system. > > In the past I did build a limited set of package (not all): > essentially I saved the binary packages of the packages I built for > me. By using alternatively two systems with a shared NFS it was > reasonably doable, but memory is an issue for certain tools. > I could try pkgsrc-2025Q3 and see how it goes! I install from the > archive and then do a pkg_rolling-replace and will run for some days! > > It is probably more reasonable to run it inside an emulator on modern > hardware for continuous service. Indeed, old systems are becoming difficult with today's bloatware. Non-TNF people are more than welcome to do builds and publish them, and I'm happy to add links to SEE_ALSO. It's just that we have a policy that binaries on netbsd.org servers must be created on machines that are entirely under the control of TNF members. If the members of port-sparc want to do builds and use them, not on ftp.netbsd.org, that's 100% fine.
