On 23 Feb 2021, at 22:51, Johannes Schauer Marin Rodrigues <josch@debian.org> wrote:
I was having a think about this last night. To be completely realistic, schroot maintenance is very low on my list of my priorities. Work on it is sporadic at best. My interest in it is also fairly low. I’ve moved on to other things. I don’t think that something which is not maintained or well supported should be used as a critical part of the Debian build infrastructure, and honestly, | think you should take steps to remove it entirely. It was a nice tool, it served its purpose, but it is dated and limited, and has been completely eclipsed by Docker. If you can switch over to using Docker, I think you should make an active effort to do so. I would also make the same case for sbuild and buildd. They are also thoroughly obsolete and could be removed. Now that you have GitLab on salsa, how much work would it be to: * create a “package-build” group owned by the current buildd admins. * hook up all the current build slaves as “runners” owned by that group. * create a “build-image” project which will use GitLab CI to build a minimal docker image for each architecture as separate jobs (can be stored in the gitlab docker registry). Have it regenerate the image weekly. Have branches for stable/testing/unstable. * create a “build” project which will do the package build. Use GitLab CI, with the container images from the previous job, install build-deps, do the build and upload. The latter can be parameterised and triggered for a given suite/package/version with a webhook. That would be several orders of magnitude simpler and more maintainable than sbuild and buildd. Just a handful of lines in a .gitlab-ci.yml and supporting shell script. If you can do that, I think that would be a much better strategy for the future. The existing tools are over 25 years old and long past due for complete replacement. schroot was an means to extend their life back in 2005. The current GitLab CI capabilities make most of their functionality redundant, and it would make sense to take advantage of that where possible. It will handle job scheduling, build log storage and browsing, everything that buildd currently does. No need for a separate database to track the archive state. Simply have the archive call a webhook when a new source package is uploaded and trigger a full build. It would also remove polling from the equation and have every action be an immediately schedulable push action. GitLab CI can make full use of all the connected runners, including parallelisation. Please feel free to forward to anyone else who might be relevant like buildd-tools or archive people. Kind regards, Roger |