Thorsten,
Regarding bug tracking, I fully support your proposal to ask LP for help with a solution.Geert Uytterhoeven dixit:I second that. In general, I would say that bootloaders don't matter that much (to have in the official Debian archives).Even then, bugtracking is an issue. And, for arch:any packages, automated builds for e.g. amd64. Launchpad could provide the former. Maybe even the latter, if we ask nicely. If there is no disagreement about that, I guess I’ll ask by the end of the month.
I fear I don't get your point about arch: any packages and automated builds. What exactly is the problem?
For all of you that have followed linux-m68k, you will have seen a huge amount of activity related to merging coldfire MMU and generic MMU code on the kernel side. As far as the userland side is concerned, I remember TLS support being suggested as solution to support generic m68k and coldfire binaries. Your work on TLS would mean that is at least withing reach now?
As for setting up autobuilders using sbuild and buildd - while I am sure that can be done both on emulated hardware and real hardware, the core problem for bootstrapping a port with a huge lot of the archive unbuilt is the build database. By far the most annoying thing about buildd used to be packages failing to build because the build dependencies were uninstallable. Finding out which build dependency was at fault was a time consuming manual process that could only be carried out post-mortem on an idle autobuilder. Sorting of build priorities based on availability of depencencies was suggested as a solution to this problem, but as long as I has to do with autobuilders this was never solved.
Unless that problem is tackled I don't see much point in setting up autobuilders. I don't have a clear solution in mind - ideally the build database host would have to check whether all build dependencies can be satisfied before placing a package in the needs-build state, and log the correct dependencies as conditionals for the dep-wait state otherwise. That way, packages should only fail to install their build dependencies if the actual buildd chroot is not sufficiently clean (handling of that could be improved by doing a dry-run install of all build dependencies by buildd before the real thing).
Keeping an up-to-date baseline package list for the build chroots is a crucial requirement for all the above, of course. We even could get the existing hosted m68k hardware (crest and kullervo) back up and running once a streamlined build database is available. But these autobuilders need somebody to inspect build logs, sign package uploads and such.
Without these things in place, sorting out real build failures (source or toolchain related) from avoidable chaff is just too much of a distraction for me to consider at this time. (My boss is overseas on research leave, adding to my workload, and I'm facing a complex lab remodeling including moving a bunch of highly sensitive equipment early next year. Planning ought to have started at least a year ago for this. Go figure! This time next year is the earliest I can look at spending time on m68k autobuilding.)
For the present, trying to keep up with Geert's pace of kernel releases and merging my Atari patches is all I can cope with, sorry.
Cheers, Michael